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From the Editor 


Welcome to Las Vegas and to NetWorld+Interop 95. This expanded 
edition of ConneXions is being provided to all attendees while 
supplies last. It contains several articles related to the conference 
and tutorial program. At the end of each article you will find pointers 
to specific conference events where you can hear more about the 
technologies being discussed in this publication. ConneXions is a 
monthly technical journal covering all aspects of computer net- 
working and interoperability. It is the only official companion public- 
ation to the conference, and has been published by Interop Company 
since the first Interop conference in 1987. For an index of our 96 
back issues, send e-mail to: connexions@interop.com. 


The Internet has been growing exponentially for several years and 
continues to outgrow even the most optimistic estimates. (See the 
results of the latest Internet Domain Survey on page 47). One aspect 
of this growth is a depletion of the available 32-bit address space. 
The Internet Engineering Task Force (IETF) has been working on 
this problem for a number of years, and has recently made a recom- 
mendation for a new version of the Internet Protocol (IP) based on a 
128-bit addressing scheme. This “IP Next Generation” (IPng) is 
described in our first article by Bob Hinden. Tim Dixon follows the 
IPng article with a look at how IPng might affect the OSI effort. 


Fibre Channel is a fusion of networking and channel approaches to 
device and system interconnection. Peter Walford and Ed Frymoyer 
describe this emerging high-speed technology. You will also be able 
to see examples of Fibre Channel systems on the exhibition floor. 


“Network Management” is almost synonymous with SNMP, the 
Simple Network Management Protocol. Originally developed by a 
small group of dedicated Internet engineers, SNMP has seen wide 
implementation deployment both inside and outside the traditional 
networking industry. SNMP++ is not a new version of SNMP, but 
rather a tool for network management programming. Kim Banker 
and Peter Mellquist give an overview of SNMP++. 


Videoconferencing is becoming a more common way to conduct busi- 
ness meetings. Traditionally, videoconferencing systems use special- 
purpose hardware and software and dedicated high-speed data lines, 
all of which come at a considerable cost. But it is possible to design 
low-cost systems using a combination of desktop computers, in- 
expensive cameras and the Internet as your backbone. Tim Dorcey 
describes the popular CU-SeeMe videoconferencing system. 


You will find more information on all of these topics in our extensive 
conference and tutorial program, and we hope you will continue to 
receive updates with a subscription to ConneXions. 
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Growth 


IP Next Generation Overview 
by Robert M. Hinden, Ipsilon Networks 


This article presents an overview of the Next Generation Internet 
Protocol which was recommended by the IPng Area Directors of the 
Internet Engineering Task Force (IETF) at the Toronto IETF meeting 
on July 25, 1994, and documented in RFC 1752, “The Recommend- 
ation for the IP Next Generation Protocol” [16]. The recommendation 
was approved by the Internet Engineering Steering Group on 
November 17, 1994 and made a Proposed Standard. 


The formal name of this protocol is IPv6 (the “6” refers to it being as- 
signed version number 6). The current version of the Internet Protocol 
is version 4 (“IPv4”). This article is intended to give the reader an 
overview of the IPng protocol. For more detailed information the 
reader should consult the documents listed in the reference section. 


IPng is a new version of IP which is designed to be an evolutionary 
step from IPv4. It is a natural increment to IPv4. It can be installed 
as a normal software upgrade in internet devices and is interoperable 
with the current IPv4. Its deployment strategy was designed to not 
have any “flag” days. IPng is designed to run well on high perform- 
ance networks (e.g., ATM) and at the same time is still efficient for 
low bandwidth networks (e.g., wireless). In addition, it provides a 
platform for new internet functionality that will be required in the 
near future. 


This article describes the work of IETF IPng working group. Several 
individuals deserve specific recognition. These include Steve Deering, 
Paul Francis, Bob Gilligan, Dave Crocker, Ran Atkinson, Jim Bound, 
Ross Callon, Bill Fink, Ramesh Govindan, Christian Huitema, Erik 
Nordmark, Tony Li, Dave Katz, Yakov Rekhter, Bill Simpson, and 
Sue Thompson. 


There are several key issues that should be considered when 
reviewing the design of the next generation internet protocol. Some 
are very straightforward. For example the new protocol must be able 
to support large global internetworks. Others are less obvious. There 
must be a clear way to transition the current large installed base of 
IPv4 systems. It doesn’t matter how good a new protocol is if there 
isn’t a practical way to transition the current operational systems 
running IPv4 to the new protocol. 


Growth is the basic issue which caused there to be a need for a next 
generation IP. If anything is to be learned from our experience with 
IPv4 it is that the addressing and routing must be capable of handling 
reasonable scenarios of future growth. It is important that we have an 
understanding of the past growth and where the future growth will 
come from. 


Currently IPv4 serves what could be called the “computer market.” 
The computer market has been the driver of the growth of the Inter- 
net. It comprises the current Internet and countless other smaller 
internets which are not connected to the Internet. Its focus is to con- 
nect computers together in the large business, government, and uni- 
versity education markets. This market has been growing at an expo- 
nential rate. One measure of this is that the number of networks in 
current Internet (40,073 as of 10/4/94) is doubling approximately 
every 12 months. The computers which are used at the endpoints of 
Internet communications range from PCs to Supercomputers. Most 
are attached to Local Area Networks (LANs) and the vast majority 
are not mobile. 


New markets 
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The next phase of growth will probably not be driven by the computer 
market. While the computer market will continue to grow at signifi- 
cant rates due to expansion into other areas such as schools (element- 
ary through high school) and small businesses, it is doubtful it will 
continue to grow at an exponential rate. What is likely to happen is 
that other kinds of markets will develop. These markets will fall into 
several areas. They all have the characteristic that they are extremely 
large. They also bring with them a new set of requirements which 
were not as evident in the early stages of IPv4 deployment. The new 
markets are also likely to happen in parallel with one another. It may 
turn out that we will look back on the last ten years of Internet 
growth as the time when the Internet was small and only doubling 
every year. The challenge for an IPng is to provide a solution which 
solves today’s problems and is attractive in these emerging markets. 


Nomadic personal computing devices seem certain to become ubiqui- 
tous as their prices drop and their capabilities increase. A key capa- 
bility is that they will be networked. Unlike the majority of today’s 
networked computers they will support a variety of types of network 
attachments. When disconnected they will use RF wireless networks, 
when used in networked facilities they will use infrared attachment, 
and when docked they will use physical wires. This makes them an 
ideal candidate for internetworking technology as they will need a 
common protocol which can work over a variety of physical networks. 
These types of devices will become consumer devices and will replace 
the current generation of cellular phones, pagers, and personal digital 
assistants. In addition to the obvious requirement of an internet 
protocol which can support large scale routing and addressing, they 
will require an internet protocol which imposes a low overhead and 
supports auto configuration and mobility as a basic element. The 
nature of nomadic computing requires an internet protocol to have 
built in authentication and confidentiality. It also goes without saying 
that these devices will need to communicate with the current gener- 
ation of computers. The requirement for low overhead comes from the 
wireless media. Unlike LANs which will be very high speed, the 
wireless media will be several orders of magnitude slower due to 
constraints on available frequencies, spectrum allocation, error rates, 
and power consumption. 


Another market is networked entertainment. The first signs of this 
emerging market are the proposals being discussed for 500 channels 
of television, video on demand, etc. This is clearly a consumer market. 
The possibility is that every television set will become an Internet 
host. As the world of digital high definition television approaches, the 
differences between a computer and a television will diminish. As in 
the previous market, this market will require an internet protocol 
which supports large scale routing and addressing, and auto configur- 
ation. This market also requires a protocol suite which imposes the 
minimum overhead to get the job done. Cost will be the major factor 
in the selection of an appropriate technology. 


Another market which could use the next generation IP is device con- 
trol. This consists of the control of everyday devices such as lighting 
equipment, heating and cooling equipment, motors, and other types of 
equipment which are currently controlled via analog switches and in 
aggregate consume considerable amounts of electrical power. The size 
of this market is enormous and requires solutions which are simple, 
robust, easy to use, and very low cost. The potential pay-back is that 
networked control of devices will result in cost savings which are 
extremely large. 


continued on next page 


3 


CONNEXIONS 


Transition 


IP Next Generation Overview (continued) 


The challenge the IETF faced in the selection of an [Png was to pick a 
protocol which meets today’s requirements and also matches the 
requirements of these emerging markets. These markets will happen 
with or without an IETF IPng. If the IETF [Png is a good match for 
these new markets it is likely to be used. If not, these markets will 
develop something else. They will not wait for an IETF solution. If 
this should happen it is probable that because of the size and scale of 
the new markets the IETF protocol would be supplanted. If the IETF 
IPng is not appropriate for use in these markets, it is also probable 
that they will each develop their own protocols, perhaps proprietary. 
These new protocols would not interoperate with each other. The 
opportunity for the IETF was to select an [Png which has a reason- 
able chance to be used in these emerging markets. This would have 
the very desirable outcome of creating an immense, interoperable, 
world-wide information infrastructure created with open protocols. 
The alternative is a world of disjoint networks with protocols con- 
trolled by individual vendors. 


At some point in the next three to seven years the Internet will 
require a deployed new version of the Internet protocol. Two factors 
are driving this: routing and addressing. Global internet routing based 
on the on 32-bit addresses of IPv4 is becoming increasingly strained. 
IPv4 addresses do not provide enough flexibility to construct efficient 
hierarchies which can be aggregated. The deployment of Classless 
Inter-Domain Routing (CIDR) [6] is extending the lifetime of IPv4 
routing by a number of years, the effort to manage the routing will 
continue to increase. Even if the IPv4 routing can be scaled to support 
a full IPv4 Internet, the Internet will eventually run out of network 
numbers. There is no question that an [Png is needed, but only a 
question of when. 


The challenge for an IPng is for its transition to be complete before 
IPv4 routing and addressing break. The transition will be much easier 
if IPv4 address are still globally unique. The two transition require- 
ments which are the most important are flexibility of deployment and 
the ability for IPv4 hosts to communicate with IPng hosts. There will 
be IPng-only hosts, just as there will be IPv4-only hosts. The capa- 
bility must exist for [Png-only hosts to communicate with IPv4-only 
hosts globally while IPv4 addresses are globally unique. 


The deployment strategy for an IPng must be as flexible as possible. 
The Internet is too large for any kind of controlled rollout to be 
successful. The importance of flexibility in an IPng and the need for 
interoperability between IPv4 and IPng was well stated in a message 
to the SIPP mailing list by Bill Fink, who is responsible for a portion 
of NASA’s operational internet. In his message he said: 


“Being a network manager and thereby representing the interests of 
a significant number of users, from my perspective it’s safe to say 
that the transition and interoperation aspects of any [Png is the key 
first element, without which any other significant advantages won’t 
be able to be integrated into the user’s network environment. I also 
don’t think it wise to think of the transition as just a painful phase 
we'll have to endure en route to a pure IPng environment, since the 
transition/coexistence period undoubtedly will last at least a decade 
and may very well continue for the entire lifetime of IPng, until it’s 
replaced with IPngng and a new transition. I might wish it was 
otherwise but I fear they are facts of life given the immense in- 
stalled base. 


History of the IPng 
effort 
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“Given this situation, and the reality that it won’t be feasible to co- 
ordinate all the infrastructure changes even at the national and 
regional levels, it is imperative that the transition capabilities 
support the ability to deploy the [Png in the piecemeal fashion... 
with no requirement to need to coordinate local changes with other 
changes elsewhere in the Internet... 


“I realize that support for the transition and coexistence capabilities 
may be a major part of the [Png effort and may cause some head- 
aches for the designers and developers, but I think it is a duty that 
can’t be shirked and the necessary price that must be paid to 
provide as seamless an environment as possible to the end user and 
his basic network services such as e-mail, FTP, Gopher, X-Window 
clients, etc... 


“The bottom line for me is that we must have interoperability during 
the extended transition period for the base IPv4 functionality...” 


Another way to think about the requirement for compatibility with 
IPv4 is to look at other product areas. In the product world, back- 
wards compatibility is very important. Vendors who do not provide 
backward compatibility for their customers usually find they do not 
have many customers left. For example, chip makers put considerable 
effort into making sure that new versions of their processor always 
run all of the software that ran on the previous model. It is unlikely 
that Intel would develop a new processor in the X86 family that did 
not run DOS and the tens of thousands of applications which run on 
the current versions of X86s. 


Operating system vendors go to great lengths to make sure new ver- 
sions of their operating systems are binary compatible with their old 
version. For example the labels on most PC or Mac software usually 
indicate that they require OS version XX or greater. It would be 
foolish for Microsoft come out with a new version of Windows which 
did not run the applications which ran on the previous version. Micro- 
soft even provides the ability for Windows applications to run on their 
new OS NT. They understand that it was very important to make 
sure that the applications which run on Windows also run on NT. 


The same requirement is also true for [Png. The Internet has a large 
installed base. Features need to be designed into an IPng to make the 
transition as easy as possible. As with processors and operating 
systems, it must be backwards compatible with IPv4. Other protocols 
have tried to replace TCP/IP, for example XTP and OSI. One element 
in their failure to reach widespread acceptance was that neither had 
any transition strategy other than running in parallel (sometimes 
called “Dual Stack”). New features alone are not adequate to motivate 
users to deploy new protocols. [Png must have a great transition 
strategy and new features. 


The IPng protocol represents the evolution of many different IETF 
proposals and working groups focused on developing an IPng. It 
represents over three years of effort focused on this topic. A brief 
history follows: 


By the Winter of 1992 the Internet community had developed four 
separate proposals for IPng. These were “CNAT,” “IP Encaps,” “Nim- 
rod,” and “Simple CLNP.” By December 1992 three more proposals 
followed; “The P Internet Protocol” (PIP), “The Simple Internet Proto- 
col” (SIP) and “TP/IX.” 
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In the Spring of 1992 the “Simple CLNP” evolved into “TCP and UDP 
with Bigger Addresses” (TUBA) and “IP Encaps” evolved into “IP 
Address Encapsulation” (IPAE). 


By the fall of 1993, IPAE merged with SIP while still maintaining the 
name SIP. This group later merged with PIP and the resulting work- 
ing group called themselves “Simple Internet Protocol Plus” (SIPP). 
At about the same time the TP/IX Working Group changed its name 
to “Common Architecture for Next Generation Internet Protocol” 
(CATNIP). [25] 


The IPng area directors made a recommendation for an [Png in July 
of 1994. This recommendation, from [16], includes the following ele- 
ments: 


e Current address assignment policies are adequate. 


e There is no current need to reclaim underutilized assigned net- 
work numbers. 


e There is no current need to renumber major portions of the 
Internet. 


e CIDR-style assignments of parts of unassigned Class A address 
space should be considered. 


“Simple Internet Protocol Plus (SIPP) Spec. (128 bit ver)” [19] be 
adopted as the basis for IPng. 


¢ The documents listed in Appendix C be the foundation of the IPng 
effort. 


e An IPng Working Group be formed, chaired by Steve Deering and 
Ross Callon. 


e Robert Hinden be the document editor for the IPng effort. 


e An IPng Reviewer be appointed and that Dave Clark be the 
reviewer. 


e An Address Autoconfiguration Working Group be formed, chaired 
by Dave Katz and Sue Thomson. 


e An IPng Transition Working Group be formed, chaired by Bob 
Gilligan and TBA. 


¢ The Transition and Coexistence Including Testing Working Group 
be chartered. 


e Recommendations about the use of non-IPng addresses in IPng 
environments and [Png addresses in non-I[Png environments be 
developed. 


e The IESG commission a review of all IETF standards documents 
for [Png implications. 

e The IESG task current IETF working groups to take [Png into 
account. 


e The IESG charter new working groups where needed to revise old 
standards documents. 


Informational RFCs be solicited or developed describing a few 
specific [Png APIs. 


The IPng Area and Area Directorate continue until main docu- 
ments are offered as Proposed Standards in late 1994. 


IPng overview 


Header format 
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Support for the Authentication Header be required. 
Support for a specific authentication algorithm be required. 
Support for the Privacy Header be required. 

Support for a specific privacy algorithm be required. 

An “IPng framework for firewalls” be developed. 


IPng is a new version of the Internet Protocol, designed as a successor 
to IP version 4 [15]. IPng is assigned IP version number 6 and is 
formally called IPv6 [14]. 


IPng was designed to take an evolutionary step from IPv4. It was not 
a design goal to take a radical step away from IPv4. Functions which 
work in IPv4 were kept in IPng. Functions which didn’t work were 
removed. The changes from IPv4 to IPng fall primarily into the follow- 
ing categories: 


Expanded Routing and Addressing Capabilities: IPng increases 
the IP address size from 32 bits to 128 bits, to support more levels 
of addressing hierarchy and a much greater number of address- 
able nodes, and simpler auto-configuration of addresses. The scal- 
ability of multicast routing is improved by adding a “scope” field 
to multicast addresses. A new type of address called a “cluster 
address” is defined, to identify topological regions rather than indi- 
vidual nodes. The use of cluster addresses in the IPng source 
route allows nodes to control the path through which their traffic 
flows. 


e Header Format Simplification: Some IPv4 header fields have been 


dropped or made optional, to reduce the common-case processing 
cost of packet handling and to keep the bandwidth cost of the 
IPng header as low as possible despite the increased size of the 
addresses. Even though the IPng addresses are four times longer 
than the IPv4 addresses, the IPng header is only twice the size of 
the IPv4 header. 


e Improved Support for Options: Changes in the way IP header 


options are encoded allows for more efficient forwarding, less 
stringent limits on the length of options, and greater flexibility for 
introducing new options in the future. 


Quality-of-Service Capabilities: A new capability is added to en- 
able the labeling of packets belonging to particular traffic “flows” 
for which the sender requests special handling, such as non- 
default quality of service or “real-time” service. 


e Authentication and Privacy Capabilities: [Png includes the defin- 


ition of extensions which provide support for authentication, data 
integrity, and (optionally) confidentiality. This is included as a 
basic element of [Png and will be included in all implementations. 


The IPng protocol consists of two parts, the basic header and options. 


Source Address 
Destination Address 


continued on next page 
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Addressing 
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The fields have the following meanings: 


Version: 4-bit Internet Protocol version number = 6. 
Flow Label: 28-bit field. See “Quality-of-service capabilities” section. 


Payload Length: 16-bit unsigned integer. Length of payload, i.e., the 
rest of the packet following the IPng header, in octets. 


Next Header: 8-bit selector. Identifies the type of header immedi- 
ately following the IPng header. Uses the same values as the IPv4 
Protocol field [21]. 


Hop Limit: 8-bit unsigned integer. Decremented by 1 by each node 
that forwards the packet. The packet is discarded if Hop Limit is 
decremented to zero. 


Source Address: 128 bits. An address of the initial sender of the 
packet. See [1] for details. 


Destination Address: 128 bits. An address of the intended recipient 
of the packet (possibly not the ultimate recipient, if an optional 
Routing Header is present). 


IPng includes an improved option mechanism over IPv4. IPng options 
are placed in separate headers that are located between the IPng 
header and the transport-layer header in a packet. Most IPng option 
headers are not examined or processed by any router along a packet’s 
delivery path until it arrives at its final destination. This facilitates a 
major improvement in router performance for packets containing 
options. In IPv4 the presence of any options requires the router to 
examine all options. The other improvement is that unlike IPv4, [Png 
options can be of arbitrary length and the total amount of options 
carried in a packet is not limited to 40 bytes. This feature plus the 
manner in which they are processed, permits [Png options to be used 
for functions which were not practical in IPv4. A good example of this 
is the [Png Authentication and Security Encapsulation options. 


In order to improve the performance when handling subsequent 
option headers and the transport protocol which follows, IPng options 
are always an integer multiple of 8 octets long, in order to retain this 
alignment for subsequent headers. 


The [Png option headers which are currently defined are: 


Option Function 

Routing: Extended Routing (like IPv4 loose source route). 
Fragmentation: Fragmentation and Reassembly. 
Authentication: Integrity and Authentication. 

Security 

Encapsulation: Confidentiality. 


Hop-by-Hop Option: Special options which require hop-by-hop processing. 


End-to-End Options: Optional information to be examined by the 
destination node. 


IPng addresses are 128 bits long and are identifiers for individual 
nodes and sets of nodes. IPng addresses refer to a single node inter- 
face. Each interface may be assigned multiple [Png addresses. There 
are three types of [Png addresses. These are unicast, cluster, and 
multicast. Unicast addresses identify a single node. Cluster addresses 
identify a group of nodes that share a common address prefix, such 
that a packet sent to a cluster address will be delivered to one mem- 
ber of the group. 
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Multicast addresses identify a group of nodes, such that a packet sent 
to a multicast address is delivered to all of the nodes in the group. 
There are no broadcast addresses in IPng, their function being super- 
seded by multicast addresses. 


IPng supports addresses with four times the number of bits compared 
to IPv4 addresses (128 versus 32). This is 4 Billion times 4 Billion (2%) 
times the size of the IPv4 address space (232). This works out to be: 


340,282,366,920,938 463 ,463,374,607,431,768,211,456 


This is an extremely large address space. In a theoretical sense this is 
approximately 665,570,793,348,866,943,898,599 addresses per square 
meter of the surface of the planet Earth (assuming the Earth surface 
is 511,263,971,197,990 square meters). 


In more practical terms the assignment and routing of addresses 
requires the creation of hierarchies which reduces the efficiency of the 
usage of the address space. Christian Huitema performed an analysis 
in [12] which evaluated the efficiency of other addressing architec- 
tures (including the French telephone system, USA telephone sys- 
tems, current Internet using IPv4, and IEEE 802 nodes). He conclu- 
ded that 128-bit [Png addresses could accommodate between 8x10"’ to 
2x1033 nodes assuming efficiency in the same ranges as the other 
addressing architectures. Even using his most pessimistic estimate 
this would provide 1,564 for addresses per square meter of the surface 
of the planet Earth. The optimistic estimate would allow for 
3,911,873,538,269,506,102 addresses per square meter of the surface 
of the planet. 


Format Prefix The specific type of IPng address is indicated by the leading bits in 
the address. The variable-length field comprising these leading bits is 
called the Format Prefix(FP). The initial allocation of these prefixes is 


as follows: 
Allocation Prefix Fraction of 
(binary) Address Space 

Reserved 0000 0000 1/256 
Reserved 0000 0001 1/256 
NSAP Allocation 0000 001 1/128 
IPX Allocation 0000 010 1/128 
Reserved 0000 011 1/128 
Reserved 0000 100 1/128 
Reserved 0000 101 1/128 
Reserved 0000 110 1/128 
Reserved 0000 111 1/128 
Reserved 0001 1/16 
Reserved 001 1/8 
Provider-Based Unicast Adr 010 1/8 
Reserved 011 1/8 
Reserved for Geographic Adr 100 1/8 
Reserved 101 1/8 
Reserved 110 1/8 
Reserved TL10 1/16 
Reserved 1111 0 1/32 
Reserved 1111 10 1/64 
Reserved 1111 110 1/128 
Reserved 1111 1110 0 1/512 
Link Local Use Addresses 1111 1110 10 1/1024 
Site Local Use Addresses 1111 1110 11 1/1024 
Multicast Addresses 1111 1111 1/256 


continued on next page 9 


10 


CONNEXIONS 


Unicast addresses 


Provider-based unicast 
addresses 


Local-use address 
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This supports the direct allocation of provider addresses, NSAP ad- 
dresses, IPX addresses, local use addresses, and multicast addresses. 
Space is reserved for geographic addresses. The remainder of the 
address space is reserved for future use. This can be used for expansi- 
on of existing use (e.g., additional provider addresses, IPX addresses, 
etc.) or new uses (e.g., separate locators and EID). 


Fifteen percent of the address space is initially allocated. The remain- 
ing 85% is reserved for future use. 


There are several forms of unicast address assignment in IPng. These 
are global provider hierarchical unicast addresses, geographical hier- 
archical addresses, NSAP hierarchical addresses, IPX hierarchical 
addresses, local-use addresses, and IP-only host addresses. Additional 
addresses types can be defined in the future. The assignment plan for 
unicast addresses is described in [3] and [2]. 


Provider-based unicast addresses are used for global communication. 
They are similar in function to IPv4 addresses under CIDR. Their 


format is: 
3 n bits m bits p bits ,125-n—m-p 
PROVIDER ID SUBSCRIBER ID SUBNET ID| NODE ID 


The first 3 bits identify the address as a provider-oriented address. A 
provider ID is assigned to Internet service providers, which then 
assign portions of the address space to subscribers. This usage is 
similar to assignment of IP addresses under CIDR. The SUBSCRIBER 
ID distinguishes among multiple subscribers attached to the provider 
identified by the PROVIDER ID. The SUBNET ID identifies a topologic- 
ally connected group of nodes within the subscriber network identified 
by the subscriber prefix. The NODE ID identifies a single node among 
the group of nodes identified by the subnet prefix. 


A local-use address is a unicast address that has only local routability 
scope (within the subnet or within a subscriber network), and may 
have local or global uniqueness scope. They are intended for use 
inside of a site for “plug and play” local communication and for boot- 
strapping up to a single global addresses. 


There are two types of local-use unicast addresses defined. These are 
Link-Local and Site-Local. The Link-Local-Use is for use on a single 
link and the Site-Local-Use is for use in a single site. Link-Local-Use 
addresses have the following format: 


10 bits n bits p bits 
Link-Local-Use addresses are designed to be used for addressing on a 


single link for purposes such as auto-address configuration. 


Site-Local-Use addresses have the following format: 


10 bits n bits m bits p bits 
For both types of local use addresses the NODE ID is an identifier 
which must be unique in the domain in which it is being used. In most 


cases these will use a node’s IEEE-802 48-bit address. The SUBNET ID 
identifies a specific subnet in a site. 


IPv4-only addresses 


Cluster addresses 


Multicast addresses 
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The combination of the SUBNET ID and the NODE ID to form a local use 
address allows a large private internet to be constructed without any 
other address allocation. 


Local-use addresses allow organizations that are not (yet) connected 
to the global Internet to operate without the need to request an 
address prefix from the global Internet address space. Local-use 
addresses can be used instead. If the organization later connects to 
the global Internet, it can use its SUBNET ID and NODE ID in combin- 
ation with a global prefix (e.g., PROVIDER ID+SUBSCRIBER ID) to create 
a global address. 


IPng unicast addresses are assigned to IPv4-only hosts as part of the 
SIT scheme for transition from IPv4 to IPng [20]. Such addresses 
have the following form: 


80 bits 16 bits 32 bits 


XXXX IP Address 


The high-order 80 bits of the address identify the address as an IPv4 
address. Bits 80-95 distinguish between an IPv4-only node and an 
IPng node. 


Cluster addresses are unicast addresses that are used to reach the 
“nearest” one (according to unicast routing’s notion of nearest) of the 
set of boundary routers of a cluster of nodes identified by a common 
prefix in the IPng unicast routing hierarchy. These are used to iden- 
tify a set of nodes. The cluster address, when used as part of a route 
sequence, permits a node to select which of several providers it wants 
to carry its traffic. A cluster address can only be used as a destination 
address. This capability is sometimes called “source selected policies.” 
Cluster addresses have the general form: 


n bits 128-n bits 
ADDRESS PREFIX CLUSTER IDENTIFIER 


The cluster identifier is an assigned identifier which is unique within 
the scope of the ADDRESS PREFIX. 


Cluster boundary routers are required to be configured to know that 
they are boundary routers and with the appropriate CLUSTER IDENTI- 
FIER(S). A boundary router may have one or more cluster addresses 
assigned to it and is required to accept datagrams addressed to the 
corresponding cluster address as being addressed to itself. 


Cluster addresses are most commonly used as intermediate addresses 
in an [Png Routing Header, to cause a datagram to be routed via one 
or more specific clusters on the way to its final destination. Cluster 
addresses must not be used as source addresses in any IPng data- 
grams. 


An IPng multicast address is an identifier for a group of nodes. A node 
may belong to any number of multicast groups. Multicast addresses 
have the following format: 


8 4 4 112 bits 
11111111 |FLGS|ISCOP Group ID 
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The fields have the following meanings: 


11111111 at the start of the address identifies the address as being 
a multicast address 


T 
FLGS is a set of 4 flags: ofofo] 


The high-order 3 flags are reserved, and must be initialized to 0. 


T = 0 indicates a permanently-assigned (“well-known”) multicast 
address, assigned by the global Internet Numbering Authority. 


T = 1 indicates a non-permanently-assigned (“transient”) multi- 
cast address. 


SCOP is a 4-bit multicast scope value used to limit the scope of the 
multicast group. The values are: 


0 reserved 8 organization-local scope 
1 node-local scope 9 (unassigned) 

2 link-local scope A (unassigned) 

3 (unassigned) B community-local scope 
4 (unassigned) C (unassigned) 

5 site-local scope D (unassigned) 

6 (unassigned) E global scope 

7 (unassigned) F reserved 


GROUP ID identifies the multicast group, either permanent or 
transient, within the given scope. 


Routing in IPng is almost identical to IPv4 routing under CIDR, ex- 
cept that the addresses are 128-bit IPng addresses instead of 32-bit 
IPv4 addresses. With very straightforward extensions, all of IPv4’s 
routing algorithms (OSPF, RIP, IDRP, IS-IS, etc.) can be used to 
route [Png. 


IPng also includes simple routing extensions which support powerful 
new routing functionality. These capabilities include: 


¢ Provider Selection (based on policy, performance, cost, etc.) 
e Host Mobility (route to current location) 
e Auto-Readdressing (route to new address) 


The new routing functionality is obtained by creating sequences of 
IPng addresses using the IPng Routing option. The Routing option is 
used by an [Png source to list one or more intermediate nodes (or 
topological clusters) to be “visited” on the way to a packet’s destin- 
ation. This function is very similar to IPv4’s Loose Source and Record 
Route option. 


In order to make address sequences a general function, [Png hosts are 
required to reverse routes in a packet it receives containing address 
sequences, in order to return the packet to its originator. This 
approach is taken to make IPng host implementations from the start 
support the handling and reversal of source routes. This is the key for 
allowing them to work with hosts which implement the new features 
such as provider selection or extended addresses. 


Three examples show how the address sequences can be used. In 
these examples, address sequences are shown by a list of individual 
addresses separated by commas. For example: 


SRC, I1, 12, 13, DST 


Quality-of-service 
capabilities 
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Where the first address is the source address, the last address is the 
destination address, and the middle addresses are intermediate 
addresses. 


For these examples assume that two hosts, H1 and H2 wish to com- 
municate. Assume that H1 and H2’s sites are both connected to 
providers P1 and P2. A third wireless provider, PR, is connected to 
both providers P1 and P2. 


The simplest case (no use of address sequences) is when H1 wants to 
send a packet to H2 containing the addresses: 


H1, H2 


When H2 replied it would reverse the addresses and construct a 
packet containing the addresses: 


H2, H1 


In this example either provider could be used, and H1 and H2 would 
not be able to select which provider traffic would be sent to and 
received from. 


If H1 decides that it wants to enforce a policy that all communication 
to/from H2 can only use provider P1, it would construct a packet 
containing the address sequence: 


H1, P1, H2 


This ensures that when H2 replies to H1, it will reverse the route and 
the reply would also travel over P1. The addresses in H2’s reply would 
look like: 


H2, P1, H1 


If H1 became mobile and moved to provider PR, it could maintain (not 
breaking any transport connections) communication with H2, by 
sending packets that contain the address sequence: 


H1, PR, P1, H2 


This would ensure that when H2 replied it would enforce H1’s policy 
of exclusive use of provider P1 and send the packet to H1’s new 
location on provider PR. The reversed address sequence would be: 


H2, P1, PR, H1 


The address sequence facility of IPng can be used for provider 
selection, mobility, and readdressing. It is a simple but powerful capa- 
bility. 

The Flow Label field in the IPng header may be used by a host to label 
those packets for which it requests special handling by IPng routers, 
such as non-default quality of service or “real-time” service. This 
labeling is important in order to support applications which require 
some degree of consistent throughput, delay, and/or jitter. 
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The Flow Label is a 28-bit field, internally structured into two sub- 


fields as follows: 
4-bit traffic class 24-bit flow identifier 


TCLASS FLOW ID 


A flow is a sequence of packets sent from a particular source to a par- 
ticular (unicast or multicast) destination for which the source desires 
special handling by the intervening routers. The nature of that special 
handling might be conveyed to the routers by a control protocol, such 
as a resource reservation protocol, or by information within the flow’s 
packets themselves, e.g., in a hop-by-hop option. 


There may be multiple active flows from a source to a destination, as 
well as traffic that is not associated with any flow. A flow is identified 
by the combination of a Source Address and a non-zero FLOW ID. 
Packets that do not belong to a flow carry a FLOW ID of zero. 


A FLOW ID is assigned to a flow by the flow’s source node. New FLOW 
IDs must be chosen (pseudo-)randomly and uniformly from the range 1 
to FFFFFF hex. The purpose of the random allocation is to make any 
set of bits within the FLOW ID suitable for use as a hash key by the 
routers, for looking up the special-handling state associated with the 
flow. A FLOW ID must not be re-used by a source for a new flow while 
any state associated with the previous usage still exists in any router. 


The TCLASS subfield provides a means separate from the FLOW ID for 
a source to identify the desired delivery priority of its packets, relative 
to other packets from the same source. The TCLASS values are divided 
into two ranges: values 0 through 7 are used to label flow-controlled 
packets, e.g., packets that belong to a TCP connection, and values 8 
through 15 are used to label non-flow-controlled packets, e.g., “real- 
time” packets being sent without any flow-control feedback from the 
receivers. 


For flow-controlled traffic, the following TCLASS values are recom- 
mended for particular application categories: 


uncharacterized traffic 

“filler” traffic (e.g., netnews) 

unattended data transfer (e.g., e-mail) 

(reserved) 

attended bulk transfer (e.g., FTP, NFS) 

(reserved) 

interactive traffic (e.g., telnet, X) 

internet control traffic (e.g., routing protocols, SNMP) 


For non-flow-controlled traffic, the lowest TCLASS value (8) should be 
used for those packets that the sender is most willing to have dis- 
carded under conditions of congestion (e.g., high-fidelity video traffic), 
and the highest value (15) should be used for those packets that the 
sender is least willing to have discarded (e.g., low-fidelity audio traf- 
fic). There is no relative ordering implied between the flow-controlled 
classes and the non-flow-controlled classes. 


The current Internet has a number of security problems and lacks 
effective privacy and authentication mechanisms below the applic- 
ation layer. IPng remedies these shortcomings by having two inte- 
grated options that provide security services. These two options may 
be used singly or together to provide differing levels of security to dif- 
ferent users. This is very important because different user com- 
munities have different security needs. 
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Transition mechanisms 


The first mechanism, called the “IPng Authentication Header,” is an 
option which provides authentication and integrity (without confi- 
dentiality) to [Png datagrams. While the option is algorithm-inde- 
pendent and will support many different authentication techniques, 
the use of keyed MD5 is proposed to help ensure interoperability 
within the worldwide Internet. This can be used to eliminate a signifi- 
cant class of network attacks, including host masquerading attacks. 
The use of the [Png Authentication Header is particularly important 
when source routing is used with IPng because of the known risks in 
IP source routing. Its placement at the internet layer can help provide 
host origin authentication to those upper layer protocols and services 
that currently lack meaningful protections. This mechanism should be 
exportable by vendors in the United States and other countries with 
similar export restrictions because it only provides authentication and 
integrity, and specifically does not provide confidentiality. The export- 
ability of the [Png Authentication Header encourages its widespread 
deployment and use. 


The second security option provided with IPng is the “IPng Encapsul- 
ating Security Header.” This mechanism provides integrity and confi- 
dentiality to [Png datagrams. It is simpler than some similar security 
protocols (e.g., SP3D, ISO NLSP) but remains flexible and algorithm- 
independent. To achieve interoperability within the global Internet, 
the use of DES CBC is being used as the standard algorithm for use 
with the [Png Encapsulating Security Header. 


The key transition objective is to allow IPng and IPy4 hosts to inter- 
operate. A second objective is to allow IPng hosts and routers to be 
deployed in the Internet in a highly diffuse and incremental fashion, 
with few interdependencies. A third objective is that the transition 
should be as easy as possible for end-users, system administrators, 
and network operators to understand and carry out. 


The Simple IP version Six Transition (SIT) is a set of protocol mecha- 
nisms implemented in hosts and routers, along with some operational 
guidelines for addressing and deployment, designed to make tran- 
sitioning the Internet to IPng work with as little disruption as pos- 
sible [20]. 


SIT provides a number of features, including: 


° Incremental upgrade and deployment: Individual IPv4 hosts and 
routers may be upgraded to IPng one at a time without requiring 
any other hosts or routers to be upgraded at the same time. New 
IPng hosts and routers can be installed one by one. 


e Minimal upgrade dependencies: The only prerequisite to upgra- 
ding hosts to [Png is that the DNS server must first be upgraded 
to handle IPng address records. There are no prerequisites to up- 
grading routers. 


e Easy Addressing: When existing installed IPv4 hosts or routers 
are upgraded to IPng, they may continue to use their existing ad- 
dress. They do not need to be assigned new addresses. Admini- 
strators do not need to draft new addressing plans. 


e Low start-up costs. Little or no preparation work is needed in 
order to upgrade existing IPv4 systems to IPng, or to deploy new 
IPng systems. 
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The mechanisms employed by SIT include: 


e An IPng addressing structure that embeds IPv4 addresses within 
IPng addresses, and encodes other information used by the 
transition mechanisms. 


e A model of deployment where all hosts and routers upgraded to 
IPng in the early transition phase are “dual” capable (i.e., imple- 
ment complete IPv4 and IPng protocol stacks). 


e The technique of encapsulating IPng packets within IPv4 headers 
to carry them over segments of the end-to-end path where the 
routers have not yet been upgraded to IPng. 


e The header translation technique to allow the eventual intro- 
duction of routing topologies that route only IPng traffic, and the 
deployment of hosts that support only IPng. Use of this technique 
is optional, and would be used in the later phase of transition if it 
is used at all. 


SIT ensures that IPng hosts can interoperate with IPv4 hosts any- 
where in the Internet up until the time when IPv4 addresses run out, 
and allows IPng and IPv4 hosts within a limited scope to interoperate 
indefinitely after that. This feature protects the huge investment 
users have made in IPv4. SIT ensures that [Png does not render IPv4 
obsolete. Hosts that need only a limited connectivity range (e.g., print- 
ers) need never be upgraded to IPng. 


The incremental upgrade features of SIT allow the host and router 
vendors to integrate [Png into their product lines at their own pace, 
and allows the end users and network operators to deploy [Png on 
their own schedules. 


There are a number of reasons why IPng is appropriate for the next 
generation of the Internet Protocol. It solves the Internet scaling prob- 
lem, provides a flexible transition mechanism for the current Internet, 
and was designed to meet the needs of new markets such as nomadic 
personal computing devices, networked entertainment, and device 
control. It does this in a evolutionary way which reduces the risk of 
architectural problems. 


Ease of transition is a key point in the design of IPng. It is not some- 
thing was was added in at the end. [Png is designed to interoperate 
with IPv4. Specific mechanisms (embedded IPv4 addresses, pseudo- 
checksum rules etc.) were built into [Png to support transition and 
compatibility with IPv4. It was designed to permit a gradual and piece- 
meal deployment with a minimum of dependencies. 


IPng supports large hierarchical addresses which will allow the Inter- 
net to continue to grow and provide new routing capabilities not built 
into IPv4. It has cluster addresses which can be used for policy route 
selection and has scoped multicast addresses which provide improved 
scalability over IPv4 multicast. It also has local use addresses which 
provide the ability for “plug and play” installation. 


The address structure of IPng was also designed to support carrying 
the addresses of other internet protocol suites. Space was allocated in 
the addressing plan for IPX and NSAP addresses. This was done to 
facilitate migration of these internet protocols to IPng. 


Additional information 


References 


The Interoperability Report 


IPng is designed to have performance better than IPv4 and still work 
well in low bandwidth applications like wireless. Its headers are less 
expensive to process than IPv4 and its 128-bit addresses are chosen to 
be well matched to the new generation of 64-bit processors. Its com- 
pact header minimizes bandwidth overhead which makes it appro- 
priate for wireless use. 


IPng provides a platform for new Internet functionality. This includes 
support for real-time flows, provider selection, host mobility, end-to- 
end security, auto-configuration, and auto- reconfiguration. 


In summary, [Png is a new version of IP. It can be installed as a 
normal software upgrade in internet devices. It is interoperable with 
the current IPv4. Its deployment strategy was designed to not have 
any “flag” days. [Png is designed to run well on high performance 
networks (e.g., ATM) and at the same time is still efficient for low 
bandwidth networks (e.g., wireless). In addition, it provides a plat- 
form for new internet functionality that will be required in the near 
future. 


A set of World-Wide Web pages is available describing [Png. The URL 
for these is: 


http://playground.sun.com/pub/ipng/html/ipng-main.html 


These Web pages contain pointers to current specifications and 
implementations and will be updated on a regular basis. 


The documentation listed in the reference sections can be found in one 
of the IETF Internet Draft directories. 


In addition other material relating to [Png (such as PostScript ver- 
sions of presentations on JPng) can also be found in the IPng working 
group archive: 


ftp.parc.xerox.com in the /pub/ipng directory. 

To join the [Png working group, send an electronic mail message to: 
majordomo@sunroof.eng.sun.com 

with “subscribe ipng” in the body portion of the message. 


An archive of mail sent to this mailing list can be found in the IETF 

directories at cnri.reston.va.us. 
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IPng—What it means for OSI 
by Tim Dixon, TDC Network Consultancy 


In March 1992, the Routing and Addressing group of the Internet 
Engineering Task Force (IETF) reported its conclusions on the funda- 
mental architectural problems of the network-layer protocol of the 
Internet (IP) which were being exposed by the rapid growth in the 
number of Internet-connected networks. The group made short-term 
recommendations to alleviate operational difficulties, but also pointed 
to the longer-term prospect of the complete exhaustion of the 32-bit IP 
address space. It therefore called for work to begin on exploring ways 
of expanding the IP address space to cope with the expected growth in 
the number of networked computer systems. 


Shortly afterwards, the Internet Architecture Board (IAB) (the “gene- 
rals” as opposed to the IETF “foot soldiers”) issued their opinion that 
the shortage of address space could be solved by using the OSI Con- 
nectionless Network Protocol (CLNP) as the basis for an IP replace- 
ment. Those who had invested in DECnet/OSI® or other CLNP-based 
networking systems congratulated themselves on their foresight. The 
IETF, however, quickly realised that the IAB decision deprived them 
of a once-in-a-lifetime opportunity to design a fundamental new net- 
working protocol and hence of an opportunity for technical immor- 
tality. The foot soldiers mutinied, the generals were deposed, and for 
over two years protocol experts arranged and re-arranged boxes 
labelled “0” to “31” on countless sheets of paper and overhead trans- 
parencies, seeking the perfect pattern. 


Finally, in the latter part of 1994, a recommendation [1] emerged 
from all this effort for an IP Next Generation Protocol (IPng) which is 
sufficiently similar in technical respects to CLNP for the IAB to claim 
that they knew what they were doing all along, and yet sufficiently 
different in detail for the IETF to claim victory. 


So, it seems that the the early adopters of CLNP congratulated them- 
selves too soon. Where does that leave those with OSI-based networks 
who were hoping for a convergence of wide-area networking tech- 
nologies? In order to answer that question, a brief look inside IPng is 
required. 


Amongst the requirements for IPng were that it should be able to 
scale to the interconnection of 1,000,000,000 separate networks, pro- 
vide security and extensibility and be simple to configure: in short 
that it should be possible to build a universal network without 
requiring universal expertise. Whether all the goals are in fact met 
depends in some measure on development work that is still to take 
place, but the main features of [Png are now known. 


The recommendation for [Png is based on work which originally went 
under the title Simple Internet Protocol and indeed the main feature 
of IPng is that it bears a striking similarity to the existing IP with 
some of the more baroque detail removed. Major differences are: 


e 128-bit network-layer addresses 

e Simplified header format 

¢ Practical source-specified routes 

e Authentication, Integrity and Confidentiality at the network layer 


¢ Elimination of fragmentation and reassembly 
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Why should OSI-users 
care about IPng? 


IPng and OSI (continued) 


One of the main arguments about IPng has been the size of the 
network-layer address. Although a process of rational argument can 
show that 64 bits are sufficient (and the same argument can show 
that 32 bits are not), delegation of assignment authority tends to 
“waste” address space in the interests of administrative simplicity. 
Coupled with the large installed base of Novell IPX-based networks 
(which have addresses of just a few more than 64 bits) the final 
recommendation of 128 bits is pragmatic. Interestingly, although the 
router manufacturers were not fazed by the prospect of variable- 
length addresses, developers of end-systems (nowadays principally 
RISC-based) argued forcefully for the fixed alignment of fields on 32- 
bit or 64-bit boundaries. 


The simplified header format reduces the amount of processing that 
needs to be done at intermediate hops along the path. Changes in the 
way that source-routing is handled means that particular paths can 
be chosen by the source through various administrative boundaries 
without the need to identify every intermediate router along the way. 


The provision of Authentication, Integrity and Confidentiality at the 
network layer answers many of the concerns that have been raised 
about the security of Internet-connected networks. Although it is 
intended that implementation of these features be mandatory, the 
effect of public policy, particularly in the area of confidentiality, may 
mean that they cannot be used in many areas of the world or that 
implementations will be subject to export controls which apply to 
cryptographic systems. 


Fragmentation in the network layer has long been deprecated, since it 
tends to have a negative effect on both throughput and effective 
utilisation of network links. In IPng all datalinks must be capable of 
transmitting and receiving packets of at least 576 octets (using 
datalink-layer protocols to achieve this if the underlying physical 
medium cannot) and a process of “discovery” will be defined to permit 
the transport layer to adapt to the largest currently-available trans- 
mission unit. 


Use of OSI, particularly in Europe, is still in many circumstances 
mandated by public policy. In other cases, it is a consequence of the 
purchase of a particular vendor-solution (such as DECnet), or the 
availability of public services (such as X.400). This article concerns 
itself with the connectionless variant of the OSI network-layer pro- 
tocol (CLNP), used by an estimated 500 to 800 thousand computer 
systems throughout the world [2]. Although similar economic con- 
siderations apply to the connection-oriented network service (typically 
provided over X.25), different technical aspects rule it out of consider- 
ation in this brief discussion. 


The rapid growth of IP both as an internal networking system within 
businesses and as a means of access to public Internet services has 
several consequences for OSI users: 


e The predominance of IP will lead to higher purchase and support 
costs for lower-volume OSI-based products and services. 


e The available choice of equipment and applications may become 
increasingly constrained and trained staff increasingly scarce. 


e Business needs for specific services may mandate access to the 
Internet, whatever the “in-house” networking protocol. 


The Interoperability Report 


Evolution of the 
mixed-protocol network 


Evolution of endsystems 
and applications 


The true test of an “Open” network is universal connectivity, and 
clearly OSI is by now a long way behind IP in terms of interoperating 
systems installed. The removal of the 32-bit addressing limit on IP 
means that OSI users should consider the “Betamax scenario” and 
reflect on whether their long term needs will be met by OSI. There is 
clearly no immediate urgency to ditch existing investment: a network 
which is meeting a business need today will still do so tomorrow. For 
some organisations, a more pressing need may be the harmonisation 
of PC-LAN protocols with their wide area networks. Even those with 
an immediate requirement for some form of Internet connectivity may 
need no more than an electronic mail gateway right now. However, a 
review of OSI policy should figure in at least the medium-term plans 
of network managers. As networked applications and new business 
needs evolve, a likely future scenario is a mixed-protocol network sup- 
porting OSI, Internet and PC-LAN applications with an increasing 
emphasis on IPng as OSI maintenance becomes less cost-effective and 
IP systems are gradually upgraded. 


Current mixed-protocol networks may be based on a single routing 
scheme which supports multiple address- and packet-formats (e.g., 
variants of the ISO IS-IS intra-domain routing protocol which also 
support IP) or on independent routing schemes for each protocol, per- 
haps sharing the same physical topology by multiplexing or encapsul- 
ation, but which are essentially separately-administered networks. 


If you have a network of integrated multiprotocol routers, you may 
wish to question your vendor closely about his plans to add IPng, as 
this may be the quickest and easiest means of introducing IPng 
support. Otherwise, careful thought should be given to the costs and 
consequences of running yet another routing protocol (even if it is only 
during a period of transition) in the network backbone. Since IP will 
remain a viable protocol long after the introduction of IPng (the aim 
being only to achieve transition before the IP address space runs 
out—currently projected to be some time after 2005 [1]), this is not a 
prospect that must be faced immediately. 


However, network managers are more likely to be attracted by the 
prospect of a reduction in the number of backbone protocols rather 
than an increase, for example by using IPng as a carrier in which 
other networking protocols can be transported. Unfortunately, al- 
though IPng can reasonably be expected to carry IP and IPX, because 
OSI NSAPs can be up to 20 octets long and IPng addresses only 16, 
CLNP into IPng won’t go. The blunt truth is that, although the Novell 
installed base is a powerful argument for going from 64 to 128 bits, 
the OSI installed base is not a powerful argument for going any 
further (although conspiracy theorists might suspect an IETF plot...). 
Two activities are underway to remedy this difficulty: to define a 
standard for “squeezing” NSAPs in commonly-used formats into IPng 
addresses and to define a way of representing IPng addresses as 
NSAPs [2, 3, 4]. There is still a final twist, though: the removal of 
fragmentation and reassembly in IPng means that even if the ad- 
dresses can be handled, the transport of CLNP in IPng must not 
result in [Png packets larger than 576 bytes. It is unlikely that carry- 
ing CLNP within IPng can be regarded as anything other than an 
interim measure in a plan to phase out CLNP altogether. 


Whatever the problems of supporting IPng within the network back- 
bone, far more difficulties result from attempting to integrate applic- 
ations and core network services. 
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Watch this space 


IPng and OSI (continued) 


A network containing DECnet, Novell and IP will also contain a 
Digital Naming Service, a Novell Directory Service and an Internet 
Domain Name System. It may provide remote access to files using the 
DEC Distributed File System, the IP-based Network File System, 
Internet FTP and OSI FTAM. Some endsystems on the network may 
support only DECnet or Novell or Internet protocols, others may sup- 
port all of them. Systems and services will be present in a variety of 
different databases, with different names, addresses and capabilities. 
Some models of the transition process from IP to IPng additionally 
require endsystems to support both IP and IPng protocols. Network 
managers are right to fear an administrative nightmare: some are no 
doubt already experiencing one. Just as it is now recognised to be a 
“bad thing” to allow users an unrestricted choice of hardware and soft- 
ware in organisations with large numbers of PCs, it is becoming 
obvious that much firmer policies may be needed in corporate net- 
working provision. The advent of IPng is a good excuse to start 
developing firm policies if they don’t already exist. 


Commercial users will have to look to vendors, service-suppliers and 
their own resources to help bring some order to this chaos and adjust 
their budgets accordingly. Non-commercial users may just have to 
plan on a little less sleep for a while. If you have a particularly com- 
plex mixed network, it may well pay to take a long look at the lifetime 
and cost/benefit of current applications to see if some can be elimin- 
ated or migrated to require a smaller number of network protocols 
during the remaining lifetime of IP. Considering a network consisting 
only of two protocols, OSI and IP, the options are: 


¢ Plan on a mixed OSI/IPng network for the future 


e Plan on an IPng-only network, moving both OSI and IP to IPng in 
the future 


e Move from OSI to IP now and from IP to IPng in the future 


Implementations are already available of the OSI applications in 
widespread use (X.400 being the most common, with some vestiges of 
X.500 and FTAM) which support IP (using the procedures of RFC 
1006) as well as the connectionless and connection-oriented variants 
of the OSI network service. Where these are in use, it may be possible 
to diminish the scope of network-layer OSI protocols within a mixed- 
protocol network by suitable re-configuration of the applications. If 
this is feasible, or if equivalent IP-based applications can be obtained, 
it may be possible to consider moving away from OSI now. Remember, 
though, that an IP to IPng transition will also be a major effort, so all 
pain is not eliminated by this process: the main reason for considering 
an OSI to IP move now would be if there were the possibility of imme- 
diate cost savings (for example from the elimination of duplicate 
naming services or administrative and support staff). 


However, there will be many cases in which a significant investment 
in OSI-only equipment or applications mandates continued OSI net- 
work-layer connectivity although newer purchases require IP. In this 
case, the network manager has to decide how long to retain OSI, and 
specifically whether it will be retained even after there is a need to 
move to IPng. At the very least, network managers should be collect- 
ing protocol-usage statistics so that trends in usage can be monitored. 


IPng is still very much “work in progress.” Features such as auto- 
configuration (which provides “plug and play” capabilities) and sup- 
port for mobile computer systems are still under development. 
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Profiles 


Providing Interoperable High Speed Connections 
with Fibre Channel Technology 


by 

Peter Walford, DemoGraFX, Inc. 
and 

Ed Frymoyer, Hewlett-Packard 


Fibre Channel [1] is the new interconnect technology that constitutes 
a fusion of networking and channel approaches to device and system 
interconnection. This fusion allows system designers to combine trad- 
itional peripheral connection, host-to-host internetworking, loosely- 
coupled processor clustering and emerging multi-media applications 
in a single multi-protocol interface. The types of channel-oriented 
facilities incorporated into the Fibre Channel framing protocol include 
data-type qualifiers for routing frame payload into particular inter- 
face buffers and link-level constructs associated with individual I/O 
operations. The types of networking-oriented facilities include full 
multiplexing of traffic between multiple destinations, peer-to-peer 
connectivity between any pair of ports on a Fibre Channel Fabric, and 
capabilities for internetworking to other connection technologies. 
Depending on the needs of the application, either channel or networ- 
king approaches can be used for any data transfer. Supported classes 
of service include dedicated connections (circuit switching—Class 1) 
and frame-level packet switching (Classes 2 and 3); isochronous capa- 
bilities including constant latency or guaranteed availability fraction- 
al bandwidth are part of a new Class of Service (Class 4) being 
incorporated into the extension of the Fibre Channel Standard, FC- 
EP. Nodes connect to Fibre Channel via adapter-level interfaces 
known as N_Ports. 


Products employing Fibre Channel are now being installed at the rate 
of hundreds of new connection paths each day in commercial, engin- 
eering, scientific, and graphical applications. Both mass storage con- 
nections as well as clustered connections are being deployed, with 
applications beginning to see the commercial benefit of Fibre Channel 
linkages at rates of 266 to 1062 Mbps with latencies in 10’s of micro- 
seconds. 


In order to foster applications built on essential common features, 
lower costs, develop multiple suppliers and most importantly to en- 
sure interoperability among suppliers, the first Fibre Channel Pro- 
files were developed by the Fibre Channel Systems Initiative (FCSI. 
FCSI, formed in February 1993 by Hewlett-Packard, Sun Microsys- 
tems and IBM (RISC 6000 Division), is developing Profiles to serve as 
high level design specifications for the development of interoperable 
Fibre Channel systems. The broad industry based Fibre Channel 
Association (FCA), which was formed in late 1993 including the FCSI 
member companies and now has over 60 members worldwide, is also 
developing Profiles for Directory Services, IPI and Fabric inter- 
operability issues. An industry ad-hoc group has developed the Fibre 
Channel Arbitrated Loop Direct Attach Disk Profile [10] as an inter- 
operability specification for direct attachment of individual disk 
drives to hosts and RAID systems using Fibre Channel. The goal of 
these profile efforts is to ensure a rapid start to the Fibre Channel 
industry by providing interoperability from the first or second gener- 
ation of equipment. 


Topologies 
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FCSI assists in the development of Interoperability Testing proce- 
dures and provides technical assistance and liaison for industry inter- 
operability testing centers. FCSI also has a major role in education 
about the benefits, attributes, and use of Fibre Channel technology 
and has staged interoperability demonstrations at 1994 Interops and 
will do so again in 1995 as ever more products come on line. 


Fibre Channel configurations cover three major types of topologies: 


e Point-to-point attachment: Devices are connected directly to each 
other over a dedicated medium. 


Switched Fabric: Devices are connected to ports on a switching 
Fabric. This switched topology provides scalability of bandwidth: 
as additional ports are added, the aggregate bandwidth of the 
Fabric increases, thereby minimizing congestion and contention 
and increasing throughput. 


e Arbitrated Loop: A low-cost shared-media topology, providing 
gigabit connections for small configurations and device attach- 
ment without the cost of a Fibre Channel Switch. Arbitrated 
Loops can be integrated into switched Fabrics, providing connec- 
tivity between hosts and devices on loops and those directly 
connected to switching Fabric ports. 


The type of topology is discovered early in the data link initialization 
process. 


The Fibre Channel standard defines a broad range of media types, 
including shortwave laser, longwave laser, copper and LED options at 
various speeds (Fibre Channel is the only draft networking standard 
with a fully-specified gigabit data link-level media option) and various 
distances. All share a common 8B/10B encoding scheme for data and 
signal integrity in different environments. The standard includes 
facilities ranging from the media connect through signaling and 
framing protocol specifications culminating in a Service Interface for 
use by Upper Level Protocols. The Fibre Channel standard family 
includes mapping standards (called FC-4s) for mapping Upper Level 
Protocol operations and services to the Fibre Channel communic- 
ations architecture. For example, there are mapping layers for SCSI 
[2] and for IP [4]. 


Nowadays, the success of computer technologies in the marketplace is 
determined by the technology’s ability to enable new applications or 
by the increase in functionality or performance that the technology 
brings to existing applications. This increased functionality or per- 
formance (ex. rate) must be provided at the same cost as existing 
technologies and with minimal changes to existing interfaces. Accord- 
ingly, the FCSI Profiles are not limited to transport-level inter- 
operability issues. Instead, the Profiles include option selections from 
the protocol-mapping layers, application-specific command sets, and 
any other intermediate standards required to ensure application-level 
interoperability. There are specific Profiles for individual applications, 
including a SCSI Profile for interoperability between Fibre Channel- 
attached SCSI devices, an IP Profile for IP host-to-host internet- 
working, etc. 


In early implementations of a new technology, interoperability prob- 
lems can result from minor differences in implementation of complex 
facilities. Complexity increases the cost and hinders the development 
of commodity components necessary for the growth of a volume 
market. 
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Fibre Channel Technology (continued) 


A major goal in the Profile development process was agreeing upon 
common simple mechanisms that could be used in multiple applic- 
ations, on different topologies and in different Classes of service which 
simultaneously enabled a broad third party supply base. 


The FCSI Profiles achieve this goal of simplicity through a process of 
option reduction. The FCSI technical teams examined each option and 
each type of behavior allowed in the relevant standards to determine 
the answers to several questions: 


e What is the effect of the option on basic interoperability (i.e., if 
one N_Port supports the option and the communicating N_Port 
doesn’t, can the two N_Ports interoperate)? 


e Does the option mandate a particular type of implementation? 


e What are the potential mechanisms that can be used to perform 
the function? 


e What is the level of complexity required in one N_Port to inter- 
operate with another N_Port that implements the function differ- 
ently? 


Simplicity of implementation safeguards against interoperability 
problems resulting from minor errors in implementation by different 
vendors. It also facilitates testing: to verify interoperability, all pos- 
sible combinations should be tested, and complex scenarios involving 
many different ways of implementing the same function require a lot 
of testing. 


The three FCSI partners had very different perspectives and ap- 
proaches to Fibre Channel implementations. Consequently, the collec- 
tive expertise of the three companies represented a broad spectrum of 
Fibre Channel technology and methodology. This ensured that FCSI’s 
consideration and evaluation of various techniques was thorough and 
comprehensive, as each company would often favor a different ap- 
proach. Whenever possible, FCSI would select only one of several 
alternative techniques, as interoperability with multiple techniques 
might require all implementations to include each method, at a 
greater risk to interoperability and at an increase in end-user cost. 


The Profiles constitute a mutually agreed-upon proper subset of the 
various standards involved in a particular application. However, there 
is considerable latitude for a wide range of cost/performance trade- 
offs: the Profiles provide for interoperability between low-cost medi- 
um-performance implementations and more expensive implement- 
ations with performance-enhancing features. 


FCSI has currently published the following Profile documents: 


e Profile Structure [5]. Describes the lexical elements and organi- 
zation of FCSI Profiles. 


e Common Feature Sets [8]. Describes features common to multiple 
FCSI Profiles, including most signaling protocol features. 


SCSI Profile [6]. Interoperability specification for SCSI hosts and 
Fabric-attached multi-drive mass storage subsystems. 


IP Profile [7]. Interoperability specification for IP hosts. 


Gigabaud Link Module Specification [9]. Component-level specific- 
ation for a family of physical interfaces. 


Examples 


Fibre Channel 
constructs 


Frames, Sequences and 
Exchanges 


Acknowledgment 
primitives 
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The types of criteria used in selecting features for the Profiles and the 
interoperability issues involved are best explored through examples. 
This section includes several technical examples illustrating features 
designed to eliminate basic interoperability problems, selection of 
features from different architectural layers required to ensure end-to- 
end application interoperability, and the Profiles’ role in forestalling 
problems commonly found in early implementations of new technol- 
ogies by defining a simple and comprehensive error recovery mecha- 
nism. 


Selected facilities from the Fibre Channel architecture are described 
here to facilitate understanding of the following examples. Specific- 
ally, the organization of Fibre Channel frames into Sequences and 
Exchanges is discussed, along with types of acknowledgment frames 
and flow control. 


Although the basic unit of data transferred on a Fibre Channel link is 
a Frame carrying between 128 and 2112 bytes of payload, the inform- 
ation unit presented at the interface to the signaling (framing proto- 
col) level is a Sequence consisting of a variable number of frames. A 
Sequence is a contiguous block of data meaningful to the particular 
Upper Level Protocol; the Fibre Channel signaling level segments a 
Sequence into frames for transmission and performs Sequence reas- 
sembly upon reception. 


Sequences are themselves grouped into Exchanges, which provide a 
mechanism for organizing multiple Sequences into higher-level con- 
structs for the convenience of applications. For example, in the Fibre 
Channel Protocol for SCSI (FCP [2]) the various command, data trans- 
fer and response Sequences associated with an individual disk oper- 
ation are grouped into a single Exchange, allowing the higher-level 
SCSI software to treat all the transport functions of the operation as a 
single atomic unit for tracking and error recovery purposes. Similarly, 
an RPC-based client-server application could treat an individual RPC 
call as a single Exchange, with the request, parameter transfer and 
return value transport functions as separate Sequences. 


At the signaling level, Fibre Channel includes three different types of 
acknowledgment frame: 


e ACK_0:a single frame used to acknowledge an entire Sequence 
e ACK_1:a frame that acknowledges an individual data frame 


e ACK N: a frame that acknowledges one or more data frames 


These acknowledgment types cannot be mixed. For example, if ACK_1 
is used, then every data frame must be acknowledged by an indi- 
vidual ACK_1 frame; and if ACK_0 is used, then one and only one 
acknowledgment frame shall be transferred for an entire Sequence 
upon successful reception of the entire Sequence. During initialization 
prior to exchanging data, the Fibre Channel architecture provides for 
a login discovery process in which a pair of N_Ports may determine 
which facilities are mutually supported. During this login process, the 
type of acknowledgment that will be used in each Class of Service for 
all communications between two N_Ports is determined. 
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Fibre Channel Technology (continued) 


Fibre Channel provides two flow control mechanisms to prevent data 
over-run and assist in congestion management: 


e End-to-End Flow Control: This type of flow control is exercised 
between the communicating N_Ports. Depending on its buffering 
capabilities, the receiving N_Port provides credit for a certain 
number of frames to the transmitter; the transmitting N_Port 
limits the number of unacknowledged outstanding frames to this 
allocated credit and regulates its transmission rate according to 
the rate of acknowledgments received. This is the only type of flow 
control available on dedicated Connections. 


° Buffer-to-Buffer Flow Control: This type of flow control regulates 
the traffic of individual frames between interface buffers at each 
stage of a frame’s progress through the packet-switching facilities 
of a Fabric. Special signaling primitives indicate the availability 
of a buffer in the next stage of the path, and a frame is held in the 
current buffer until the next buffer is available. This prevents 
data overrun at destination N_Ports and at each switching ele- 
ment along the path; however, it is less effective at reducing 
congestion than the End-to-End mechanism. 


The interaction between Fibre Channel’s flow control mechanisms, 
classes of service and acknowledgment types required careful study 
within FCSI. For example, the ACK_0 acknowledgment type could not 
provide interoperability between N_Ports with different levels of on- 
board buffering in Class 1. Figures 1 and 2 show the relationship 
between on-board buffering and flow control when using dedicated 
Connections. 


Frames received into adapter memory must be eventually transferred 
across the system bus into host memory. If on-board memory is avail- 
able, an adapter should be able to receive frames at link rate from the 
Fibre Channel. Flow control is not necessary as long as there is 
sufficient on-board memory to receive the incoming data. However, 
the adapter may be unable to transfer frames at link rate from on- 
board buffers to host memory due to system-level bus contention, 
context switching overhead, and other activity in the host. The trans- 
mission of acknowledgment frames allows a recipient to notify the 
transmitter that on-board buffers are available to receive incoming 
frames; the recipient can withhold those acknowledgments when on- 
board buffers are full pending transfer of received frames to host 
memory. 
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Figure 1: Flow control with large on-board buffering 
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Figure 1 shows an adapter with sufficient on-board buffering to 
receive an entire 64 KByte Sequence transferred as 64 1K frames. As 
the entire Sequence can be received in the interface board prior to 
transferring it to host memory, End-to-End flow control is un- 
necessary and the entire Sequence can be acknowledged with a single 
ACK_0 frame. Even if each data frame is acknowledged with an indi- 
vidual ACK_1, the entire Sequence will still be transmitted without 
flow control as the End-to-End credit value is 64 buffers. 


On the other hand, Figure 2 shows an adapter with only 2 1KByte 
buffers on-board. Once this adapter has received two frames, over-run 
can only be prevented if the transmitter refrains from sending 
additional frames until it receives an indication that the on-board 
buffers are again available. Consequently, an ACK_0 cannot be used 
to acknowledge the entire Sequence as ACK_0s provide no inform- 
ation for intra-Sequence flow control. If ACK_1 is used, then the 
transmitter will not send more than two frames without acknowledg- 
ment as the End-to-end Credit value is only two. As each frame is 
transferred to host memory, the receiving adapter sends an ACK_1 
frame indicating than an on-board buffer is available, and the entire 
Sequence can be transmitted without over-run. 


The FCSI Profiles should provide for interoperability across a range of 
price/performance optimizations in adapter design; and the level of 
on-board buffering is a major differentiator between adapters with 
different price/performance levels. Accordingly, use of ACK_0 is pro- 
hibited in Class 1 in Profile-compliant operations [8]. 
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Figure 2: Flow control with minimal on-board buffering 


TCP/IP on Fibre The previous example demonstrated selection of Fibre Channel 
Channel signaling layer options to ensure basic interoperability. A major part 
of each Profile (and all of the Common Feature Sets document) is 
devoted to interoperability at the Fibre Channel level. However, as 
indicated previously, ensuring interoperable application support also 
involves option selection in Upper Level Protocols and among applic- 
ation features that use those protocols. The following example illust- 
rates how the TCP/IP Profile [7] specification ensures that IP hosts 
implement compatible TCP/IP and ARP features to enable maximum 
throughput and connectivity. 
continued on next page 99 
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The implementation of TCP/IP on Fibre Channel is a straightforward 
process similar to its implementation on other LAN technologies. 
Mapping TCP/IP onto Fibre Channel constructs is defined in an IETF 
Internet Draft [4], which should be upgraded to proposed standard 
status in the near future. 


The FCSI TCP/IP Profile stipulates that IP packets can be sent across 
Fibre Channel Fabrics in either the Connection-oriented Class of 
Service (Class 1) or the acknowledged Connectionless Class of Service 
(Class 2). In this context, the Connection-oriented Class of Service 
(Class 1) should not be confused with transport-layer TCP con- 
nections. A Fibre Channel Connection provides a dedicated path 
through a Fibre Channel Switching Fabric; all resources and link 
facilities along the path between two N_Ports are locked down at 
Connection establishment, providing guaranteed in-order delivery at 
full link bandwidth. Establishment and tear-down times for these 
Connections are very short (10—40 microseconds on current Fabrics), 
and for TCP/IP traffic these Connections will be very short-lived. In 
heavily utilized environments, a separate Fibre Channel Connection 
may be established for each IP packet. 


The acknowledged Connectionless Class of Service (Class 2) provides 
for multiplexed traffic at the frame level (an IP packet may be sent as 
many 2K byte frames) with notification of delivery between multiple 
concurrently active N_Ports. Buffer-to-buffer flow control ensures that 
frames are not accepted into the Fabric unless switching buffers are 
available to route them; so that Fabrics can respond to temporary 
congestion by not accepting frames rather than discarding data due to 
statistically overcommitted bandwidth allocations. 


Individual IP packets are sent as separate Fibre Channel Sequences. 


. Many IP packets can be sent in a single Fibre Channel frame (maxi- 


mum size if 2112 bytes); these are transmitted as single-frame 
Sequences and require no fragmentation or reassembly. Larger pac- 
kets are sent as multi-frame Sequences, fragmentation into multiple 
frames and reassembly at the destination are performed by Fibre 
Channel protocol chips in the adapters. A large IP Maximum Trans- 
mission Unit (MTU) size (62580 bytes on Fibre Channel [4]) can be 
used as both Class 1 and Class 2 provide guaranteed delivery (on 
networks that respond to congestion by dropping frames or cells, large 
MTU sizes are not practical as the entire packet will need to be re- 
transmitted if a small cell is dropped). In data-intensive applications, 
throughput is improved with a large MTU size: a host interrupt is 
required per packet, and fewer interrupts are required with larger 
packets. 


Measured TCP/IP throughput on Fibre Channel is very impressive. 
For example, IBM has reported inter-workstation TCP throughput of 
17 Mbytes/sec across a Fabric using standard 25 Mbytes/second Fibre 
Channel optical links, and there are no barriers to this throughput 
scaling up as gigabit interfaces become available later this year. 


As Fibre Channel throughput is high, the FCSI TCP/IP Profile recom- 
mends that TCP implementations incorporate the TCP Options and 
Extensions for performance on high-speed LANs described in “TCP 
Extensions for High Performance” [12]. 


Address resolution 


Error recovery 


The Interoperability Report 


These extensions include the following mechanisms supported by TCP 
options negotiated at TCP connection establishment: 


e Window Scale: TCP option that provides for increasing the TCP 
window of unacknowledged data from the standard limit of 64K 
bytes to up to 1G byte. 


e Accurate Round-trip Time measurement: this increases the accu- 
racy of round-trip time (the time interval between sending a TCP 
segment and receiving the acknowledgment) measurement at 
negligible computational cost on TCP connections using large win- 
dows on very high bandwidth networks. This mechanism requires 
the TCP Timestamp option. 


¢ Protection against Wrapped Sequences: improves data integrity by 
protecting against inadvertent data corruption associated with 
delayed delivery of retransmitted data after a TCP Sequence 
Count wraparound has occurred (the probability of such wrap- 
arounds is much greater with high bandwidth networks). This 
mechanism also requires the TCP Timestamp option. 


As with all LANs, address resolution capabilities are necessary to pro- 
vide plug-and-play level TCP/IP interoperability on Fibre Channel. 
Address Resolution on Fibre Channel is provided by an adaptation of 
the standard ARP protocol; the general mechanism is described in the 
Internet Draft [4]. In combination with the FCSI TCP/IP Profile, ARP 
support is specified for the three Fibre Channel topologies as follows: 


e Point-to-Point: each workstation responds to ARP requests sent 
from the directly attached node. 


Fabric-attached: Address resolution is provided by an ARP Server 
accessed via a well-known address on the Fabric. Each IP node 
registers its IP and Fibre Channel addresses with the ARP Ser- 
ver, and nodes needing IP-to-Fibre Channel address translation 
query the ARP Server for this information (this mechanism is 
very similar to that used by “Classical IP over ATM” [11]). The 
FCSI Profile specifies that these requests will always be per- 
formed in Class 2, simplifying ARP Server implementation. 


e Arbitrated Loop (FC-AL): as this uses a shared medium similar to 
traditional LANs, broadcast support on this topology is easily 
implemented. ARP requests are sent out as broadcast frames, and 
the node with the requested IP address unicasts a response to the 
ARP request originator. 


Robust, reliable error recovery is a critical component of inter- 
operability. Frame corruption due to transmission errors occurs with 
any data communications technology, although the frequency of er- 
rors, error detection capabilities, and error correction and recovery 
facilities vary a great deal. The robustness of error detection and 
recovery facilities is often poorly understood during initial standard 
development; the experience and analysis gained from early imple- 
mentation efforts is required to understand the most practical level of 
error recovery mechanisms to implement and evaluate the tradeoffs 
between frequency of errors, efficiency of recovery mechanisms, and 
cost and complexity of implementation. 


Error recovery constituted a major focus of FCSI’s Profile develop- 
ment efforts. It was particularly important to correctly determine the 
appropriate level of recovery and the degree of complexity and sophis- 
tication required. 
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Standard conformant mechanisms ranged from resetting the physical 
link to immediate retransmission of Sequences containing errors to 
forced logout of an N_Port after communications failures. Successful 
error recovery with any of these mechanisms requires an exact inter- 
operable match between the operations performed by one N_Port and 


those of the N_Port with which it is communicating. 


To ensure interoperability among early implementations, a single 
simple error recovery mechanism sufficiently flexible for recovery 
from all anticipated errors was considered preferable to requiring a 
battery of more sophisticated mechanisms that might provide more 
efficient recovery from particular types of errors. More sophisticated 
mechanisms could be added in the future, after experience with early 
implementations and once basic heterogeneous interoperability had 
been achieved. 


Errors in Fibre Channel environments are expected to be quite in- 
frequent. This is due to the low bit error rate of the transmission 
media employed, the resiliency of the encoding scheme, and the mini- 
mization of congestion through the flow control mechanisms in the 
various Classes of Service. In this environment, simplicity of imple- 
mentation and broad applicability of a recovery mechanism is more 
important than minimizing overhead. Maintenance of data integrity 
and reliable return to a predictable known state after errors are 
critical. The same mechanism should be available for Upper Level 
Protocol initiated error recovery (e.g., termination of a disk operation 
after an operation-specific time-out) as for data link level recovery. 


The Fibre Channel architecture provides for error recovery at any of 
four levels: 


e Link level, where errors in transmission of individual frames 
result in link-level resets. 


e Sequence level, where errors (including frame-level errors) are 
corrected by abnormal termination and retransmission of the 
Sequence, if possible. 


e Exchange or operation level, where upon any error the entire oper- 
ation (possible involving many Sequences, each of which is com- 
posed of many frames) is aborted and retried according to the 
recovery requirements of the particular application. 


e N_Port level, where recovery to a known state requires a tempor- 
ary loss of the ability to communicate between two N_Ports 
followed by re-login. 


These levels constitute a hierarchy of progressively more compre- 
hensive recovery mechanisms. Link level recovery is necessary if link 
integrity is compromised; however, link resets can cause frames in 
transit to be discarded leading to a requirement for Sequence level 
recovery. Exchange level recovery can always correct Sequence level 
errors, but Sequence level recovery is insufficient if entire Sequences 
are lost or if an entire operation must be aborted at the request of 
higher level software. The N_Port level is the most drastic, and is only 
appropriate if other mechanisms have failed. 
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All N_Ports must implement link-level recovery to maintain integrity 
and synchronization along the transmission link. Of the four mecha- 
nisms, Sequence-level recovery is the most complex; as the state of 
individual Sequences must be tracked and adapters must be capable 
of retransmitting particular Sequences. Exchange level recovery 
would still be required even if Sequence-level recovery was available. 


Profile-compliant error recovery occurs at the Exchange (i.e., oper- 
ation) level; attempts to invoke Sequence-level recovery are pro- 
hibited. As errors should be infrequent and Exchange level recovery 
would always be required for certain types of errors, the selection of 
Exchange level recovery represents a significant simplification that 
ensures data integrity and robustness of Fibre Channel applications. 
For SCSI operations, Exchange-level recovery means that the entire 
I/O operation is aborted and may be retried. Error recovery in IP 
applications is always provided above the data link level (Fibre Chan- 
nel for IP simply provides a transmission facility for datagrams of up 
to 64K bytes in length), Exchange-level error recovery simply restores 
the Fibre Channel transport mechanism to a known state. As most IP 
hosts might also use Fibre Channel for SCSI disk operations, the 
FCSI Profiles provide for an identical error recovery mechanism for IP 
and SCSI. 


Error recovery specifications are neither complete nor interoperable 
unless errors that occur during the error recovery process are them- 
selves addressed. The FCSI Profiles provide for limited attempts to 
repeat failed error recovery operations; followed by implicit logout of 
the destination N_Port if the retry fails. If communications with a 
particular N_Port have become impossible due to the frequency of 
errors encountered, this ensures that all operations with that N_Port 
are terminated. Communications can be re-established by re-login 
once the situation causing frequent errors has been corrected. 


The FCSI Profiles represent a unique effort to ensure multi-vendor 
interoperability among early implementations of a complex new giga- 
bit interconnect technology. These Profiles include selections among 
all options required for application-level interoperability. Through 
thorough specification of all interoperability features including error 
recovery, the Profiles provide a platform for the rapid development of 
Fibre Channel products to meet the growing bandwidth demands of 
data communications and mass storage in the workstation market- 
place. 
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SNMP++: 
A Portable Object Oriented Approach to 
Network Management Programming 


by Kim Banker and Peter E. Mellquist, Hewlett-Packard Co. 


Various Simple Network Management Protocol (SNMP) [1] Applic - 
ation Programming Interfaces (API) exist which allow for the creation 
of network management applications. The majority of these APIs pro- 
vide a large library of functions which require the programmer to be 
familiar with the inner workings of SNMP and SNMP resource mana- 
gement. In addition, most of these APIs are platform specific, result- 
ing in SNMP code specific to an operating system, network operating 
system, or network management platform. Application development 
using C++ has entered the main stream, and with it a rich sets of re- 
usable class libraries are now readily available. Up to now, a standard 
set of well designed C++ classes for network management have been 
missing. An object oriented approach to SNMP network programming 
provides many benefits including portability, ease of use, safety, and 
extensibility. SNMP++ offers power and flexibility which would other- 
wise be difficult to implement and manage. 


SNMP++ is a set of C++ classes which provide SNMP services to a 
network management application developer. SNMP++ is not an ad- 
ditional layer or wrapper over existing SNMP code. Rather, SNMP++ 
coexists with existing SNMP libraries in a few minimized areas and 
in doing so is efficient and portable. SNMP++ is not meant to replace 
other existing SNMP APIs or libraries such as WinSNMP, instead it 
offers power and flexibility which would otherwise be difficult to man- 
age and implement. SNMP++ brings the object oriented advantage to 
network management programming! 


The most important features of SNMP++ are: 


e Portability across Operating Systems and Network Operating 
Systems 


e Full SNMP version I Support 

e Get, Set and Get-Next 

e Trap Reception 

e Session Model 

e Transport Layer Independence 

e Blocked or Asynchronous Modes 

e Extensibility through C++ Sub-classing 


SNMP++ offers full functionality for all SNMP version I services. This 
includes, SNMP get, set, get-next and trap reception. SNMP++ is 
designed to be transport layer independent. SNMP++ supports a ses- 
sion model, where a session is defined by a logical connection to a 
managed agent. Sessions are managed through different instances of 
SNMP++ SNMP objects. An application may utilize multiple sessions, 
each corresponding to a different, or same agent. The maximum num- 
ber of sessions are limited only by the number of available User Data- 
gram Protocol (UDP) or Internet Packet Exchange (IPX) sockets. 
SNMP++ supports two modes of operation, blocked and asynchronous. 
Blocked mode provides automatic retry and timeout for Protocol Data 
Unit (PDU) delivery. Together, blocked and asynchronous modes, give 
the application developer the flexibility to develop powerful network 
management applications. 
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SNMP++ (continued) 


Perhaps the best way to introduce SNMP++ is through a small exam- 
ple which illustrates its power and simplicity. The following example 


is 


taken from a Microsoft Windows application, but is portable across 


other platforms. The example obtains an SNMP Management Infor- 
mation Base (MIB) system descriptor object from the specified agent. 
Included is all code needed to create an SNMP session, get an octet 
variable, and print it out. Transmission retry, time-out and SNMP 
resource allocation are managed automatically. Those readers who 
have written similar code using WinSNMP or other comparable 
SNMP APIs should appreciate the simplicity and power which 
SNMP++ provides. 


{{=---=--- [ SNMP++ get system descriptor example code ]--------- 
#include "snmp.h" 
void get_system_descriptor( HWND hWnd) 


{ 


}3 


long int err_status, err_index; int status; char msg[255]; 


Vb vb; // Construct a snmp++ 
// variable binding object 
vb.set_oid("1.3.6.1.2.1.1.0"); // Load the vb object with 


// sys descriptor ID 


// Construct an SNMP object with xport type, 
// dest context, & return status 
Snmp snmp( hWnd, (Protocol) ip, "public", &status); 


// Invoke get member function at agent IP address 15.29.33.10 
status = snmp.get( &vb, 1, err_status, err_index,16, "15.29.33.10"); 
if ( status == 0) 
vb.get_value( msg); // Extract a char array from 
// the returned vb object 
else 
sprintf( msg, "SNMP++ Error = %d", status); 
// Error from get request 


// Display the sys descriptor ID value 
MessageBox( hWnd, msg, "SNMP++ Demo", MB_OK); 


// That's all ! 


The actual SNMP code is made up of only five calls. Two SNMP++ 
objects are utilized, the Variable Binding (Vb) and the SNMP object. 
The Vb object is constructed and two public member functions are 
utilized. vb::set_oid, sets the Oid portion of the Vb object. 
Vb: :get_value extracts an octet array from the returned Vb object. 
SNMP++ set and get-next requests are almost identical. That is, they 
utilize identical parameter lists. 


A 


major design goal of SNMP++ was to provide a portable SNMP API 


across a variety of operating systems (OSs), network operating sys- 
tems (NOSs), and network management platforms. This is accomp- 
lished by hiding the internal mechanisms of SNMP and providing a 
generic interface to SNMP services. A program which uses SNMP++ 
does not have to change SNMP code to move to another platform. 


Platforms which SNMP++ have been successfully deployed include: 


e MS-Windows 3.1 

e MS-Windows For Work Groups 3.11 

e MS-Windows NT (Win16 subsystem) 

e MS-Windows ’95 Beta II (Win16 subsystem) 

e HPUX version 9.0, series 700 & 800 workstations 
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Figure 1: Portability of SNMP++ 


Another issue in the area of portability is the ability to operate over a 
variety of transport layer protocols. SNMP++ currently operates over 
the Internet Protocol (IP/UDP) or IPX protocols, or both using a proto- 
col stack that supports both IP and IPX concurrently. 


An Object Oriented approach to SNMP programming should be easy 
to use. After all, SNMP is supposed to be a simple network manage- 
ment protocol! An application programmer should not need be con- 
cerned with low level SNMP mechanisms. An object oriented ap- 
proach to SNMP encapsulates and hides the internal mechanisms of 
SNMP, and in doing so provides safety from inadvertently doing the 
wrong thing. A user does not have to be an expert in SNMP to use 
SNMP++. Furthermore, a user does not have to be an expert in C++! 
Basic knowledge of SNMP is required, but only a minimal under- 
standing of C++ is required. 


In addition to providing ease-of-use, SNMP++ preserves SNMP flexi- 
bility. A number of commercial applications have been successfully 
created using SNMP++. SNMP++ is designed to be flexible and multi- 
purpose. Much of this flexibility and power would be difficult to imple- 
ment and manage using a traditional API. To permit greater flexi- 
bility and extensibility, the application programmer may subclass the 
base SNMP++ classes to provide specialized behavior and/or attri- 
butes. This theme is central to object orientation. The base classes of 
SNMP++ are meant to be generic and do not contain any vendor spec- 
ific data structures or behavior. New attributes can be easily added 
through C++ sub-classing and member function redefinition [5]. 


Most SNMP APIs require the programmer to manage a variety of 
resources [2]. These include: 


e Object Id’s (Oids) 

e Variable Bindings (Vbs) 

e Variable Binding Lists (Vbls) 
e Protocol Data Units ( PDU) 

e Context Names 


e Authentication Structures 
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Improper allocation or deallocation of these resources often results in 
corrupted or lost memory. SNMP++ provides safety by managing 
these resources internally. A user of SNMP++ does not have to be con- 
cerned with providing reliability for an unreliable transport mecha- 
nism. SNMP++ includes built-in error checking and automatic time- 
out and retry mechanisms to provide the user with transparent 
reliability. 


SNMP++ classes SNMP++ is based around three C++ classes; the Oid Class, the Vb 


Vendor Specific Blocked SNMP 


Class, and the SNMP class. SNMP++ was designed using the Object 
Modeling Technique (OMT). OMT is a well known Object Oriented 
Methodology which allows detailed modeling of objects including their 
relationships and associations [3]. 
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Figure 2: OMT (Object Modeling Technique) View of SNMP++ 


Oid class The Object Identification (Oid) class is the encapsulation of an SNMP 
object identifier. The Structure of Management Information (SMI) Oid, 
its related structures and functions, are a natural fit for object orient- 
ation. In fact, the Oid class shares many common features to the C++ 
String class [7]. For those readers familiar with the C++ String class 
or Microsoft Foundation Classes (MFCs) Cstring class, the Oid class 
will be familiar and easy to use. 


The Oid class is designed to be efficient and fast. Do not make the 
false assumption that by using C++, a performance penalty must be 
paid. A well encapsulated C++ class is easier to fine tune than the 
equivalent C code [4]. The Oid class allows definition and manipul- 
ation of object identifiers, mostly through overloaded C++ operators. 
The Oid Class is fully portable and does not rely on WinSNMP or any 
other Windows or Unix SNMP API to be present. The Oid class may 
be compiled and used with any ANSI C++ compiler. The Oid class 
includes all the related SMI types for Oids. A complete description of 
the Oid class can be found in the SNMP++ document [6]. 
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[J a a [ SNMP++, Oid Class Examples ]----------------- 
// A few simple Oid Class examples, see the SNMP++ document 

// for all examples 

void oid_examples() 


{ 


Oid ol; // construct an empty oid object 
Oid o2( "1.253.4.5"); // construct an oid using a dotted string 
Oid 03( 02); // construct an oid using another 


// oid object 


o3 += 1; // concat a 1 to 02 

// making it 1.2.3.4.5.1 
printf( "%s",o3.strval());  // print out o3 as a dotted string 
o3 = "1.3.6.8": // reassign o3 to a different 

// dotted string 


if ( 03 == "1.3.6.8") // overloaded equivalence operator for 
printf( "03 = 1.3.6.8"); // comparison 


} // automatic cleanup when Oids go out of scope! 


The Variable binding (Vb) class represents the encapsulation of an 
SNMP SMI variable binding. A variable binding is the association of 
an SNMP object ID with its SMI value. In object oriented method- 
ology, this is simply a “has a” relation. A Vb object “has a” Oid object 
and “has a” SMI value. The Vb class allows the application program- 
mer to instantiate Vb objects and assign the Oid and value portions. 
Conversely, the Oid and value portions may be extracted. The public 
member functions are overloaded to provide the ability to set or get 
different values to the Vb binding. Variable binding lists in SNMP++ 
are represented as arrays of Vb objects. All SMI types are provided 
within the Vb Class. The Vb class provides full data hiding. The user 
does not need to be concerned about SMI value types, Oid repre- 
sentations, or other related SNMP structures. Like the Oid class, the 
Vb class is fully portable using a standard ANSI C++ compiler and is 
not dependent on other SNMP libraries. 


[1-------------MM [ SNMP++, Vb Class Examples ]------------------ 
// A few simple Vb Class examples, see SNMP++ document 

// for all examples 

void vb_examples() 


{ 


Vb vb1; // construct a single vb object 
vb vbs[10]; // construct an array of 

// 10 Vb objects 
Oid of di ("1.2.3 .4.5"); // construct an oid object 

// with a dotted string 
int x; 
Oid oid2; // construct an empty oid object 
vb1.set_oid("1.2.3.4"); // assign the oid portion of the vb 
vbs[0].set_oid( oid1); // set the oid portion of vbs[0] 
vb1.set_value( (int) 22); // set value portion of vb1 

// to an int, value 22 
vbs[0].set_value( oid1); // set value portion of vbs[0] 

// to an oid, oid1 
vb1l.get_value ( x); // extract an integer value 

// from vb1 
vbs[0].get_value( oid2); // extract oid object from vbs[0] 


} // automatic cleanup when Vbs go out of scope! 
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The most important class in SNMP++ is the SNMP class. The SNMP 
class is an encapsulation of a SNMP session. An SNMP session in- 
cludes a logical connection from an SNMP management station to a 
managed agent or agents. Handled by the session are the con- 
struction, delivery and reception of SNMP PDUs. Most APIs require 
the programmer to directly manage the session. The SNMP class 
manages a large part of the session and frees the implementor to 
concentrate on the agent management. Through utilization of the 
SNMP class for session management, the implementor may reuse well 


‘developed and tested code. The alternative is to design, implement 


and test your own SNMP engine. The SNMP class manages a session 
by: i 


e Managing the transport layer over a UDP or IPX connection. 
e Serializes and un-serializes the SNMP++ objects 

e Provides for delivery and reception of PDUs 

e Manages all necessary SNMP resources. 


The SNMP class is easy to use. Three basic methods, Snmp::get, 
Snmp::set and Snmp::get_next provide the basic functions for a net- 
work management application. Multiple sessions may be used, each 
asynchronously firing simultaneous requests. 


The SNMP class interface is portable across OSs and NOSs. The 
implementation of the SNMP class is platform specific. That is, it is 
implemented for each OS and NOS platform. Currently this module 
has been ported to run on MS-Windows over WinSNMP and HPUX. 
The amount of coding needed to port SNMP++ to other platforms is 
minimal. To the application programmer, no code changes are re- 
quired to move from one platform to the next. The vast majority of 
SNMP++ is re-used across platforms; thus, development time and 
testing time are cut drastically. 


SNMP++ is an API created at Hewlett-Packard Roseville Networks 
Division that permits network management application developers to 
create SNMP applications. SNMP++ is a very easy to use, portable, 
flexible, and extensible set of C++ classes that allows a programmer 
to focus more on the network management application and less on the 
details and maintenance of a complex SNMP API. 


SNMP++ is more than just an API. SNMP++ is also a field tested wor- 
king implementation. There are a variety of HP network management 
applications which have been successfully implemented and ported 
across platforms using SNMP++. Possible future directions for 
SNMP++ will include more OS and NOS support and enhancements 
for SNMP version 2. 
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Introduction 


Conference control 


The CU-SeeMe Desktop Videoconferencing Software 
by Tim Dorcey, Cornell University 


CU-SeeMe is a desktop videoconferencing system designed for use on 
the Internet or other IP networks. It runs on Macintosh and Windows 
platforms and requires no special equipment for video reception 
beyond a network connection and gray-scale monitor. Video trans- 
mission requires a camera and digitizer, a combined version of which 
can be purchased for the Macintosh for under $100. CU-SeeMe video 
is represented on a 16-level gray scale, and is provided in either of 2 
resolutions: 320 x 240 pixels (half diameter of NTSC television) or 160 
x 120 pixels. At this writing, audio is available in the Macintosh 
version only, with audio processing adapted from the Maven program, 
written by Charlie Kline at the University of Illinois. When network 
conditions or equipment deficiencies prohibit reliable audio, ordinary 
telephone connections can be employed. In addition to basic audio/ 
video services, CU-SeeMe offers crude white board capabilities in the 
form of a “slide window” that transmits full-size 8-bit gray scale still 
images and allows for remote pointer control. A plug-in architecture 
has also been developed to allow 3rd parties to write binary modules 
which extend the capabilities of CU-SeeMe. Two-party CU-SeeMe 
conferences can be initiated by one participant connecting directly to 
the other, whereas larger conferences require that each participant 
connect to a “CU-SeeMe reflector,” a Unix computer running CU- 
SeeMe reflector software that serves to replicate and re-distribute the 
packet streams. 


The main objective in the development of CU-SeeMe was to produce 
an inexpensive videoconferencing tool that would be usable today. As 
well as providing direct benefit to its users, we expected that valuable 
lessons could be learned about how videoconferencing actually works 
in practice, how the experience should be organized, what features are 
necessary to support multi-party conferencing, and so on. While 
others worked to advance the state of the art in video compression, 
high-speed networking, and other low-level technologies necessary to 
support high quality videoconferencing, we hoped to facilitate the 
accumulation of experience that would provide impetus for those 
efforts and guide their direction. 


Similar efforts have focused on Unix workstations, for which several 
tools are currently available, including nv [1], ive [2] and vic [8]. In 
fact, it was Paul Milazzo’s [4] demonstration of such a tool in 1991 
that inspired development of CU-SeeMe. However, it is our belief that 
the value of a communication tool is largely determined by the num- 
ber of people that can be reached with it. We sought to increase the 
accessibility of videoconferencing by focusing on low-end, widely 
available, computing platforms. Currently, CU-SeeMe can be found in 
places ranging from the grade school to the national laboratories— 
often with a connection between them. It has appeared in over 40 
countries [5] and on every continent—including Antarctica [6]. This 
article presents a brief overview of two central components of the CU- 
SeeMe software: Conference Control and Video Encoding. 


Each participant in a CU-SeeMe conference periodically transmits a 
single packet that advertises their interests with respect to all of the 
other participants. These advertisements are termed “OpenContinue” 
packets, in recognition of the fact that in a connectionless protocol the 
information necessary to open a connection is no different than that 
used to continue it. The OpenContinue packet consists of a standard 
header that is common to all CU-SeeMe packets, followed by a section 
of general information about the issuing participant. 


Video encoding 
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Then, for each other participant that the sender is aware of, follows a 
collection of variables that express the sender’s interests with respect 
to that other participant (e.g., I want their video, I want their audio, I 
want their slides, etc.). Reflectors examine OpenContinue packets to 
develop source specific distribution lists for the various media in- 
volved in a conference and then forward them to all other partici- 
pants. Because the protocol requires each participant to process dyna- 
mic status information for every other conference participant, it does 
not scale well to large conferences, say larger than about 30. However, 
it does provide considerable control, in a robust fashion, over the 
details of smaller conferences. Furthermore, various possibilities, 
beyond the scope of this discussion, exist for extending the protocol to 
larger conferences. 


The primary motivation for developing the reflector software was the 
absence of multicast capabilities on the Macintosh. We have therefore 
been careful about extending its role beyond the replication and 
distribution of packets, allowing it to add value where it can, but 
avoiding dependence on it. We have, however, increasingly come to 
appreciate the degree to which the reflector architecture allows for 
fine tuning of the data streams sent to each recipient, and we do not 
expect this to become any less important when multicast becomes 
more widely available. 


The predominant objective here was to devise algorithms that would 
be fast enough for real time videoconferencing on the typical Macin- 
tosh platforms that were available in mid-1992, which mainly con- 
sisted of 68020 and 68030 based machines. The decoding algorithm, in 
particular, needed to be extremely efficient in order to support mul- 
tiple incoming video streams. The main technique for achieving these 
goals was to begin with a massive decimation of the input video 
signal, and then to process what remained in a manner that took 
maximal advantage of the capabilities of the target processors, as 
described below. For simplicity, discussion will focus on the smaller 
size video format, which has become most popular in practice. Video 
processing proceeds in 3 basic steps: 1) decimation 2) change detection 
and 3) spatial compression. 


The first step in the video encoding is to decimate the captured 640 x 
480 pixel video frame down to 160 x 120, with each pixel represented 
on a 4-bit gray scale. In comparison to full size, 16-bit color, this 
represents a 64:1 reduction in the amount of data to be handled by 
subsequent processing. The user is provided with brightness and 
contrast controls to adjust the mapping of input intensities to the 16 
level gray-scale. With proper adjustment and reasonable lighting con- 
ditions, surprisingly good picture quality can be achieved. 


Next, the video frame is subdivided into 8 x 8 pixel squares, and a 
square is selected for transmission if it differs sufficiently from the 
version of it that was transmitted most recently. The index used to 
measure square similarity is the sum of the absolute value of all 64 
pixel differences, with an additional multiplicative penalty for pixel 
differences that occur nearby one another. Inclusion of the multi- 
plicative penalty was based on the assumption that changes in adja- 
cent pixels are more visually significant than isolated changes. Its 
exact form was dictated by computational convenience, devised so as 
not to introduce any additional computational burden except during 
the initialization of a look-up table at program load time. 


continued on next page 
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CU-SeeMe (continued) 


To account for the possibility that updates may be lost in transit, 
transmission is also triggered if a square has not been transmitted for 
a specified number of frames (refresh interval). This ensures that a 
lost update will not corrupt the image into the indefinite future. 


Once a square has been selected for transmission, a locally developed 
lossless compression algorithm is applied. The most interesting fea- 
ture of this algorithm is the degree of parallelism it achieves by 
manipulating rows of 8 4-bit pixels as 32-bit words. This allows for 
high-speed performance on a 32-bit processor, but also complicates 
exposition of the algorithm. The basic idea is that a square row is 
often similar to the row above it, and, when it is different, it is likely 
to be different in a consistent way across columns. Letting r/i/ repre- 
sent a 32-bit word containing the ith row of pixels in a square, com- 
pression is based upon the representation: r/i/ = rfi-1] + d[i], where 
dfi] is constructed from either a 4, 12, 20 or 36 bit code. If d/i/ is 
thought of as being composed of 8 4-bit pixel differences, then spatial 
redundancy in the vertical direction suggests that the differences will 
all be near to 0, whereas correlation in the horizontal direction sug- 
gests that they will be near in value to each other. Under those 
assumptions, the sorts of d/i/ that are most likely to occur can be 
predicted and a scheme devised to represent them using a relatively 
small number of bits. Roughly speaking, for each d/i/, a 4-bit code is 
used to specify a) a common component of all pixel differences (restric- 
ted to the range /—2, 2/) and b) whether there are 0 ,8, 16 or 32 bits of 
additional data to represent deviations around that constant compo- 
nent. In reality, of course, d/i/ is not composed of individual pixel 
differences, since carry bits can occur in the 32-bit arithmetic, but the 
technique still seems to work reasonably well, achieving around 40% 
compression (compressed size is approximately 60% of original). 
Although a 40% compression ratio may not appear impressive, recall 
that this is for images that have already undergone a 64:1 decimation 
from the original, and that the information discarded at the outset 
was that most suitable for compression. 


The CU-SeeMe video encoding has proven to be surprisingly robust 
against packet loss when the subject matter is a typical talking head. 
Often, the only observable effect of high packet loss is a reduction in 
frame rate. This can be explained as follows. After decimation and 
compression, it is almost always the case that the information re- 
quired to update a frame will fit within a single (less than 1,500 byte) 
packet. Hence a lost packet corresponds to a lost frame update, rather 
than a partial frame update. Secondly, when the subject is a talking 
head, most squares are either changing every frame or not at all. 
Hence a square update that is lost was likely to be replaced in the 
next frame anyway. Only when a square changes, but then does not 
change in the next frame, will corruption occur. 


This suggests a simple method for embedding several frame rates 
within a single video stream. Say, every 3rd frame, transmit a square 
if it is different than it was in the preceding frame orif it is different 
than it was 3 frames ago. Recipients who desire a slower frame rate 
could accept every 3rd update and still get a clean video image. The 
observations regarding packet loss suggest that this would not intro- 
duce a great deal of additional traffic i.e., a square that differs from 3 
frames ago is also likely to differ from the preceding frame. Some 
variation on this scheme will be implemented in an upcoming version 
of CU-SeeMe to better support conferences involving participants 
with differing network capacity. 
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Notes and references 


More about CU-SeeMe: 
BOF: Wednesday night 
See BOF flyer for details. 


CU-SeeMe employs a conference control protocol that has proven to be 
quite robust and allows for the expression of detailed state regarding 
the relations of each conference participant to each other participant. 
In conjunction with the reflector software it allows for customized 
distribution of conference media, so that nothing is transmitted un- 
less it will be used. The protocol is limited in the size of a conference 
which it can serve, but it can be extended. 


CU-SeeMe video is encoded in an ad hoc format that was designed for 
a particular family of desktop machine that were widespread in mid 
1992. What it lacks in mathematical elegance, it makes up for in 
quickness. As computing power increases, it will eventually become 
obsolete. Nonetheless, it played an essential role in making CU- 
SeeMe interesting enough to warrant further work, and it, or its deri- 
vatives, will continue to play an important role for some time. 


CU-SeeMe can be obtained from: 


ftp: //cu-seeme.cornell.edu/pub/video 
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Submissions 


Important dates 


More information 


Announcement and Call for Papers 


The IFIP/IEEE International Conference on Distributed Platforms, 
ICDP ’96, will be held in Dresden February 27—March 1, 1996. 


Client-Server applications are of increasing importance in industry, 
and have been enhanced with advanced distributed object-oriented 
techniques, dedicated tool support and both multimedia and mobile 
computing extensions. Such solutions are a significant step towards a 
global distributed processing model. Recent responses to this trend 
are standardized platforms and models including the Distributed 
Computing Environment (DCE) of the Open Software Foundation 
(OSF), Open Distributed Processing (ODP) and the Common Object 
Request Broker Architecture (CORBA) of the Object Management 
Group (OMG). 


ICDP ’96 will be a major forum for distributed systems researchers, 
network developers, service providers, application designers and end 
users for discussing the latest research and development results with 
respect to these platforms. Topics of particular interest include, but 
are not limited to: 


e Experiences with distributed applications and standardized plat- 
forms (DCE, CORBA, ODP, ONC+, ANSAware and others) 


e Distributed platforms in advanced development/research projects 
e Network Services (directory, security, file management etc.) 

e Distributed application management 

e Objects in distributed environments 

e Trading concepts and open markets of distributed services 

* Quality of service in distributed applications 

e Applications of mobile communication systems 


The conference is organized into a Technical Stream where the latest 
research results will be presented, an Industrial Stream where Indus- 
trial developments and trends will be discussed and a Demonstration 
Stream which features an exhibition around distributed processing. 
Original full papers (max. 15 pages) will belong to the Technical 
Stream. Furthermore, you are invited to submit extended abstracts 
focusing on practical work for both the Industrial Stream and the 
Demonstration Stream (max. 5 pages). Accepted papers will be pub- 
lished in the international conference proceedings by Chapman & 
Hall. All submissions must be sent online (PostScript) to the following 
e-mail address: ICDP96@ibc.inf.tu-dresden.de 


Deadline for Submission: June 15, 1995 

Notification of Acceptance: September 15, 1995 

Camera ready papers: October 15, 1995 

For further information please contact the program chairs: 

Prof. Dr. Alexander Schill Prof. Dr. Otto Spaniol/Claudia Popien 
Dresden Univ. of Technology RWTH Aachen 

Dept. of Computer Science Computer Science IV 

D-01062 Dresden D-52056 Aachen 

GERMANY GERMANY 


URL: http: //www.inf.tu-dresden.de/TU/Informatik/IBDR/1srn/ICDP96 
FAX: +49 351 4575 335 


More information 


Subscription 
information 


1995 
NetWorld+Interop 
events 
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Internet Domain Survey: January 1995 
Number of Hosts, Domains, and Nets: 


Replied Network Class 


Date Hosts Domains To Ping* A B Cc 
Jan 95 4,852,000 71,000 970,000 91 4979 34340 
Oct 94 3,864,000 56,000 1,024,000 93 4831 32098 
Jul 94 3,212,000 46,000 707,000 89 4493 20628 
Apr 94 —N/A- 

Jan 94 2,217,000 30,000 576,000 74 4043 16422 
Oct 93 2,056,000 28,000 69 3849 12615 
Jul 93 1,776,000 26,000 464,000 67 3728 9972 
Apr 93 1,486,000 22,000 421,000 58 3409 6255 
Jan 93 1,313,000 21,000 54 3206 4998 


[* estimated by pinging 1% of all hosts] 


The Internet Domain Survey attempts to discover every host on the 
Internet by doing a complete search of the Domain Name System. 
The latest results gathered during late January 1995 are listed above. 
For more information see RFC 1296. This survey was produced by 
Mark Lottor of Network Wizards and the data is available on the 
Internet at http: //www.nw.com/ 


Write to ConneXions! 


We'd love to hear your comments, suggestions and questions about 
anything you read in ConneXions. Our editorial address is given 
below. Use it for letters to the Editor, questions about back issues etc.: 


ConneXions—The Interoperability Report 

303 Vintage Park Drive, Suite 201 

Foster City, CA 94404-1138 

USA 

Phone: +1 415-578-6900 or 1-800-INTEROP (Toll-free in the USA) 
Fax: +1 415-525-0194 

E-mail: connexions@interop.com 

URL: http://www.interop.com 


For questions about your subscription please call our customer service 
hotline: 1-800-575-5717 or +1 502-493-3217 outside the USA. This is 
the number for our subscription agency, the Cobb Group. Their fax 
number is +1 502-491-8050. The mailing address for subscription pay- 
ments is P.O. Box 35840, Louisville, KY 40232-9496. 


This publication is distributed on an “as is” basis, without warranty. Neither the 
publisher nor any contributor shall have any liability to any person or entity with 
respect to any liability, loss, or damage caused or alleged to be caused, directly or 
indirectly, by the information contained in ConneXions—The Interoperability 
Report® 


+ INTEROP’ 95 
Frankfurt, Germany May 29-June 2 
Tokyo, Japan July 17-21 
== Paris, France September 11-15 
3 Atlanta, Georgia September 25-29 
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